Trevor, I am a member of serveral other Technical Forms. When i have found problems with any software, have brought it up on several occasions. A few of these issues were acknowledged by the Software Vendor and later architectural changes were made to rectify the issue.
On this Forum, i have rarely heard anybody talk about Problems OF UV... Why? Perhaps they are too big Loyalists of UV to approve of the Problem.... Do you know what this leads to...the Vendor is never going to improve the software, unless the Clients asks for more.. Do you think VB.NET will Perform better than C#.NET? C# is a strongly typed language, just like java...this helps it Peform and scale better. Our UV Developers tell me, everything in UV is treated as Strings.. Do you think MATH Functions will Perform better in UV than a DataBase that supports DataTypes? A String can be any Possible Combinations, so the the underlying Language/Compiler takes more time to achive the same results. Leave alone MATH... Try some BIG Loops. Another Big Problem..Unicode on any MainStream Database is a very easy thing to do.. No effort required. We were trying to get Unicode into UV For about 4 Months. We failed and finally had IBM Consultants come in to help.. Even they couldnt get it done. Finally, we decided to store all Unicode in MS-SQL Server until IBM gets things resolved. Do you think this is a good situation? Yes, MainStream DataBases are Complex because they do ALOT of STUFF. I have written applications that were entirely Data Logic Driven(Business Logic, Rules Logic, Data Intergrity Logic etc). There applications were highly scalable and responded in LESS 300 MILLISECONDS PER REQUEST. On the contrary... The UV Programs i have come across treat UV as a Flat File, Data Dump Mechanism. Then the UV Developer uses PICK/BASIC to Read the Data and ALL the Logic is Embeded within these PICK/BASIC Programs. So you are taking the Data out of its Container and doing a TON of Data Interpreting... WHERE ALOT OF these can be BASED on RELATIONAL DATA. E.G. Lets say you have to Process Order Taxes Based on Country Code and State Code. Our UV Developers write a PICK/BASIC Program like if(countryCode == 'USA' & stateCode == 'NY') read some file with data... else if (countryCode == 'USA" & stateCode=='SC') read some file and do this... So for every Country and State.... you are goona do the above.. Why NOT just relate the data between the combinations within the DB with Data Relations...and just leave the data where it belongs... Hell alot of LESS Code.. right? You can clearly see where Procedural Technique is Highly In-Efficient. Thanks, Joe Eugene >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Trevor Ockenden >Sent: Monday, March 29, 2004 9:55 PM >To: U2 Users Discussion List >Subject: Re: Modern Universe - was: The lists are closing > > >Joe > >One final point. You find it hard to believe people on this LIST get so >defensive. > >May I suggest that if we were to dive into a DB2 or SQLServer LIST (if they >exist) and put them down I dare say we would get some pretty >abusive remarks >thrown at us too. > >Only to be expected > >Trevor Ockenden >OSP > > > >--- >Outgoing mail is certified Virus Free by AVG 6.0. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.642 / Virus Database: 410 - Release Date: 24/03/2004 > >-- >u2-users mailing list >[EMAIL PROTECTED] >http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
