Re: SQL -> Oracle
- From: "Marcelo [RM Sistemas]" <lombii@xxxxxxxxx>
- Date: Mon, 23 Jan 2006 11:42:55 -0300
thanks everyone!
"Didier Gasser-Morlay" <didiergm@xxxxxxxxxx> escreveu na mensagem
news:43d34d8a$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Marcelo
>
> I faced that bridge a while back and did the following
>
> 1- went to SQL-Direct (www.sql-direct.com)
> - fast (uses native links)
> - multi-database
> - works in Delphi Pro
> - not too far from BDE (has tsdQuery replace tquery)
>
> 2- extracted all my SQL queries in one single file (that was the tedious
> part). So when I build, I build with one platform in mind so I include the
> correct version of the SQL.inc. Adding a new platform is merely
> translating this one single file into the specific SQL jargon of the
> target db. with modern DB engines the syntax and capabilities are now very
> close (especially Oracle and Firebird) so the task at hand it not too
> enormous.
>
> 3- now whenever I need new query. I drop the proper component, write the
> query, test it as much as I want, when I am happy I copy it as a constant
> in the big SQL file and voila! if I build for a platform for which I
> forgot to translate a query, I get a nice (!) compile-time error message.
>
> No ifs in the source code, Exe is smaller and faster as it does not carry
> any extra baggage.
>
> The main diffence you're going to have is with Stored procedures
>
> - Sybase and SQL server need a Getresults call to get the return code of
> a stored procedure
> - Sybase and SQL server prefix their parameters with '@'
> - Firebird and Oracle have selectable stored procedures so you use them
> as tables in a query not in a SP component
> - Oracle has sequences whilst Sybase (or MS) don't AFAIK but
>
> these are just implementation details, which need considering
>
> All the above, with a little care can probably be encapsulated in a
> derived class by I have not (yet) had to do that (laziness ?) so I have a
> few ifs.
>
> ha, last point. instead of dropping straigth a tsdquery or a
> tsdStoredproc, derive them immediatly into an object tMarceloQuery and
> tMarceloSP. So if you encounter a pb later on (like Selectable Sps need a
> tquery not a tStoredproc), you will just have to put some flesh into your
> derived components and not worry about have to trawl through 300 units to
> change object classes.
>
> hope this helps
>
> Didier
>
> Marcelo [RM Sistemas] wrote:
>> I reaaly would you to comment about the situation below described:
>>
>> I have a Delphi project with more than 300 units, accessing SQL
>> Server with BDE (using regular TQuery and TDatabase).
>>
>> We here, don´t want to be limited to only SQL Server customers,
>> having also Oracle customers. And, once we will be already doing a big
>> work on updating (some functions wich works fine at SQL, don´t at Oracle)
>> , we are considering to forget about BDE, and use something else, like
>> ADO.
>>
>> Questions:
>>
>> - Considering costs/benefits, wich solution should i implement ? I
>> really don´t want to update my system so bad, and after that have this
>> system turned to
>> something else, but in the other hand, i really want to forget about BDE.
>>
>> - Is there a component, to replace the TQuery component, wich
>> automatically converts query texts from SQL to Oracle ? Or i will have to
>> write a lot of IFs, in order to
>> use one query text or another, depending if the connection is to a SQL
>> Server or Oracle.
>>
>> - All of our future Oracle customers, will use Oracle clients, so
>> that´s not a problem.
>>
>> - Any other solution to have this done ?
>>
>>
>> Thanks in advance
>>
>>
.
- References:
- SQL -> Oracle
- From: Marcelo [RM Sistemas]
- Re: SQL -> Oracle
- From: Didier Gasser-Morlay
- SQL -> Oracle
- Prev by Date: Re: Anyone finding programmers via the ...delphi.jobs NG?
- Next by Date: Re: Anyone finding work on the ...delphi.jobs NG?
- Previous by thread: Re: SQL -> Oracle
- Next by thread: Ping Xananews non-techies
- Index(es):
Relevant Pages
|
