John, Basically, it comes down to a cultural (as in PICK community preference). The logic is that dictionaries are cheap, easy, and reusable, so why not create a virtual field. Back in the bad old days database structures were fairly rigid constructs. PICK was one of the only models that maintained a very clear separation of data field definition from the actual data. So the habit/technique/culture was to take advantage of that flexibility.
Today you have a choice. You can create "virtual fields" on the fly in a retrieve statement. At least you can in UV. The exact syntax is not at my finger tips as I don't use it often (I prefer to create a dictionary) but it is covered in the manuals. As I recall it is only slightly more complicated than a similar function in SQL. Of course, as someone mentioned earlier, you do have the option of doing SQL syntax in UV today too. Having created complex reports both in UV and in native SQL (non-U2 database) my opinion is that SQL is stronger in creating complex relational reporting and retrieve is better at quick column oriented reports. Once you know the language neither is significantly more difficult than the other. They both have strengths and weaknesses. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aherne, John Sent: Thursday, February 17, 2005 6:29 PM To: [email protected] Subject: RE: [U2] uv pe True, I really shouldn't write off anything that I am not informed about, but we have programmers here that have been programming Unidata since time immemorial and they don't know how to do something like a select statement that converts criteria into caps for comparison. E.g. SELECT blah WITH UPCASE(x) LIKE "...HELLO..." (Doesn't work, but is what I want to do). The best answer I got was create a virtual field that stored the field in caps and then use that in the select. In fact, the example in an old Unidata manual I found says to do just that. Perhaps there is good reasoning behind that method, but the logic of it completely escapes me. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Lakeland Sent: Thursday, February 17, 2005 2:02 PM To: [email protected] Subject: RE: [U2] uv pe John, There is also a huge amount of things which can be done with a "single line query" in both UD and UV. Because you don't know how to do them does not mean they cannot be done. As you say, you are new, it's an unwise man who rubbishes a product he knows little about. Suggest you ask a few questions, especially on the issues which take so much time to do. Andy -----Original Message----- From: Aherne, John [mailto:[EMAIL PROTECTED] Sent: 17 February 2005 20:31 To: [email protected] Subject: RE: [U2] uv pe Ease of development? Very little support required? I have just started to use UD, and development is horrific, it take 10 times longer to do things that can be accomplished by a single line query in an RDBMS'. Our system requires constant attention, more attention than even MS Sql server on a bad week. But the thing that annoys me most is the poor support from IBM. I cannot get access to some of their tech docs because our UD license is held by our VAR (Don't ask). What kind of policy is that? For any other DBMS I can get access to vast amounts of information, and I don't even need to have seen the software, nevermind have a license. I looked forward to working with UD when I found out I would be developing on it, I have never used an mvdbms before, and the concept intrigued me. But so far, I do not see any benefit to using UD for anything what-so-ever, and nothing IBM or our VAR has provided has even hinted that UD, and UV are anything but an archaic relic of times gone by, like COBOL. Why else would a company make it so difficult for someone to learn about development on their software, if not because they didn't really have any interest in supporting it, and believe that you should have upgraded to more modern technology already? Regards, John Aherne ------- 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/
