RE: [U2] .Net Provider for Unidata or Universe
Tony, IBM's .net integration is real soon now. We are talking in terms of a few weeks, not months. To speed this up further we should email LeRoy each day asking is it here yet! Cheers. -Original Message- From: Tony Gravagno [mailto:[EMAIL PROTECTED] Sent: Thursday, 17 June 2004 11:07 AM To: [EMAIL PROTECTED] Subject: RE: [U2] .Net Provider for Unidata or Universe George Smith wrote: As I have told you before I am not interested in Raining Data and I for one wish you would stop your touting. My posting did have a little RDC and a smiley but since you'd like to approach this more seriously... I make my recommendations based on my sense of good business, not idle touting. The touting and smiles just decorate my business recommendations, even though I stand to gain absolutely nothing from the commentary. With the thousands of postings to this forum George, it's tough to remember who's p.o'd at who, and who likes or doesn't like a given product. When I see a question, I post an answer if I have one. Going back through my archive I now see you've lost about 6 months of development time asking the same question a few times with no suitable answer, and waiting for some other solution to come by. In that same time I've seen others in your position develop and deploy their solutions using the tools that are available. The song says if you can't be with the one you love, honey, love the one you're with. In the business world when we don't move fast enough we lose opportunities, so similarly, it's often best to use the tools that are available now rather than waiting for something else. I don't know what your priorities are, but when I see you've gone so long without a solution I figured it was time for a reminder so that you could re-weigh those options for yourself. FWIW, you don't need third-party tools to connect into your MV environments. The tools are created and sold to fill a void where developers don't want to develop their own. There's nothing more magical or high quality about provided tools than DIY solutions, except that you don't have to maintain them yourself. The other side of that coin is that you _can't_ maintain these other tools on your own, so you may be better off writing your own tools, which may cost much less in the long run than buying, even if you need to contract someone to write the tools for you. I think the reason you're waiting for UO.NET is that you've found the other connectivity libraries to be inadequate, but you're hoping that someone will still provide a free or low-cost alternative. Many people here hate those libs and others love them, to each his/her own. But if IBM can't get the existing libraries to work for you now, then it's unlikely they're going to come up with something new that will change that in the near time-frame. Sure we can hope and trust, but it's going to take IBM time to develop, beta, and deploy a new library, and then there is the initial bleeding edge v1.0 honeymoon/pain that developers have to tolerate, so you aren't looking at a real solution for quite some time yet. With all this in mind I thought you might be more inclined to try a proven solution that's available immediately, rather than waiting for ... whatever. Good Luck. Tony [EMAIL PROTECTED] Frequently hating RD and other companies as much as anyone... --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] [Ignore] back online - testing u2users list for bouncing
Regards, Scott Richardson Senior Systems Engineer / Consultant Marlborough, MA 01752 --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] How keep '\' in unix/uniVerse filenames?
Karl Pearson wrote: Try putting two \\ so the escape will be used as it was meant to be, to keep special characters from being treated like special characters. I.e. \* \? \\ etc. The difficulty is in doing this. Once the shell has the value with the '\' in it, it becomes very hard to manipulate it. You might get away with doing a 'tr' or a 'sed' in between the 'find ... -print' and the 'while read', but you'd have to be very clever with the escaping of your escapes in the sed script or the tr strings. Cheers, Ken LeRoi Keiller wrote: Cutdown example of what I'm trying to do (ksh): $ ls TRAN* TRAN.EXT-14320S1??\4-DF TRAN.EXT-14320S1??\5-DF (note the '\' in the file names) $ find TRAN* -print | while read file do ls -l $file done TRAN.EXT-14320S1??4-DF not found --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] Transactions and ON ERROR and Triggers and client access.
TRANSACTIONS and ON ERROR Another issue exists with ON ERROR within a transaction, at least when it was implemented back in the early to mid nineties. I have not tested it recently and Ardent, Informix or IBM may have addressed it, but if a transaction was active and a situation arose which normally would require the ON ERROR clause to be taken then it would not be and from memory the program would abort. TRIGGERS and client access I have also come across and issue where access to a table with a trigger on caused Universe Objects to cause a core dump on the server side. Has anyone experienced this in recent releases. Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gyle Iverson Sent: Saturday, June 19, 2004 3:14 PM To: [EMAIL PROTECTED] Subject: RE: [U2] [UV] WHILE READNEXT id DO Ray Wurlod opined: Personally, I love this syntax. When training others, I usually explain it in this form; READNEXT has to generate a true/untrue value of some kind to determine whether to go down its THEN or ELSE path. We take advantage of that Boolean context to trigger the behaviour of WHERE or UNTIL in a looping context. READNEXT is not the only statement that exhibits this behaviour. Almost any statement that has THEN/ELSE can use it. But READNEXT, READSEQ/READBLK are the most sensible. [snip] It would be nice were there a section in the BASIC manual about the Boolean context of certain statements, but that's only a minor complaint. Of course, each statement syntax that appears to make at least one of THEN or ELSE mandatory would need a note referring to this section. Hello, Ray. We can agree that the syntax has a certain appeal, yet finding a practical use for such has always escaped me in real applications for anything but READNEXT. Why? The syntax precludes handling of ON ERROR or LOCKED clauses. Never mind that the READNEXT, READSEQ and READBLK statements should [but do not] have an ON ERROR clauses. After all, files may be damaged or networks may be interrupted. I assume your sensible reference would not be so if these statements should later support such a clause. Writing robust, recoverable, error-tolerant code precludes taking the approach that a file I/O statement may have only a THEN or ELSE condition. Perhaps if there were a structured exception mechanism within BASIC one could safely use such syntax, but I discourage its use for anything but simple one-time utility programs. Best regards, Gyle --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Transactions and ON ERROR and Triggers and client access.
I ran into a problem recently with the PICK version. Another Uv bug caused a file not to be opened, this caused a fatal at the write under transaction control and did not take the on error clause. I suspect that one of the major errors that this clause would have to handle in many cases is if the File Variable is not a valid pointer and I don't think the on error clause works properly if this file variable is invlaid. This would probably relate to many issues including triggers and transactions. What flavour are you working on? Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Walker Sent: Sunday, 20 June 2004 7:32 AM To: [EMAIL PROTECTED] Subject: [U2] Transactions and ON ERROR and Triggers and client access. TRANSACTIONS and ON ERROR Another issue exists with ON ERROR within a transaction, at least when it was implemented back in the early to mid nineties. I have not tested it recently and Ardent, Informix or IBM may have addressed it, but if a transaction was active and a situation arose which normally would require the ON ERROR clause to be taken then it would not be and from memory the program would abort. TRIGGERS and client access I have also come across and issue where access to a table with a trigger on caused Universe Objects to cause a core dump on the server side. Has anyone experienced this in recent releases. Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gyle Iverson Sent: Saturday, June 19, 2004 3:14 PM To: [EMAIL PROTECTED] Subject: RE: [U2] [UV] WHILE READNEXT id DO Ray Wurlod opined: Personally, I love this syntax. When training others, I usually explain it in this form; READNEXT has to generate a true/untrue value of some kind to determine whether to go down its THEN or ELSE path. We take advantage of that Boolean context to trigger the behaviour of WHERE or UNTIL in a looping context. READNEXT is not the only statement that exhibits this behaviour. Almost any statement that has THEN/ELSE can use it. But READNEXT, READSEQ/READBLK are the most sensible. [snip] It would be nice were there a section in the BASIC manual about the Boolean context of certain statements, but that's only a minor complaint. Of course, each statement syntax that appears to make at least one of THEN or ELSE mandatory would need a note referring to this section. Hello, Ray. We can agree that the syntax has a certain appeal, yet finding a practical use for such has always escaped me in real applications for anything but READNEXT. Why? The syntax precludes handling of ON ERROR or LOCKED clauses. Never mind that the READNEXT, READSEQ and READBLK statements should [but do not] have an ON ERROR clauses. After all, files may be damaged or networks may be interrupted. I assume your sensible reference would not be so if these statements should later support such a clause. Writing robust, recoverable, error-tolerant code precludes taking the approach that a file I/O statement may have only a THEN or ELSE condition. Perhaps if there were a structured exception mechanism within BASIC one could safely use such syntax, but I discourage its use for anything but simple one-time utility programs. Best regards, Gyle --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
