Re: ANSI SQL COMPATIBILITY

The problem is not writing standard SQL. That is the easy part! The problem is to get the best performance you have to know something of how the API works and think about what you are going to do. The most common problem I have seen in large GUI systems is data efficiency. I mean retrieving only what you need the minimum number of times you need it. You would be surprised when you get more than two software engineers on a project how they don't realize that.
Jim

matta_at_metratech.com wrote in message <71su9l$3hv$1_at_nnrp1.dejanews.com>...
>Hello All
>
>Our system needs to be database vendor independent. We will be mainly
>talking to MS SQL Server, Oracle, Sybase and maybe IBM-DB/2. My questions
>are:
>
>1) Are all these vendors following one standard for SQL coding, ie. ANSI
 SQL.
>I think MS and Sybase have their version of SQL called Transact-SQL.
>
>2) What are the common pitfalls of ANSI SQL coding? I am sure it works
 well
>with native commands but might not work for little complicated stuff like
>datepart, etc... Our queries (as of now) are very simple and will probably
>work for all kinds of vendors. However, I do not want to rule out the idea
>of having some tricky joins as well as using in-built functions.
>
>3) Is there a FAQ on this or some research that somebody has already done
 on
>it?
>
>Please either respond to this post or mail me at matta_at_metratech.com,
>whichever is convenient.
>
>Thanks
>
>Raju Matta
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Received on Fri Nov 06 1998 - 00:00:00 CST