Subject | Re: [ib-support] INTERBASE to SQL SERVER |
---|---|
Author | Nando Dessena |
Post date | 2002-04-05T08:48:12Z |
Todd,
I'll add my two cents here.
find many missing features, but you may find the general inconsistencies
in SQL Server's design rather frustrating at first.
I'll add to what Daniel said that triggers are executed once per batch
(as opposite to one per touched record as it is in InterBase) and that
transaction control is totally different (ie you can, and in many
instances you must, control transactions in triggers and stored
procedures). This may mean a lot of work depending on your application.
applications.
If you use the "native" driver you are going to have trouble.
Personally, I have never been able to make it work properly with a live
TQuery; the UpdateMode setting is not respected (it always behaves as if
upWhereAll was specified) and it also tries to do pessimistic locking on
edit (I'm not jocking) by issueing a select count(*) when you call the
Edit method. It works with TTable, but it is irrelevant since you are
not going to use TTable anyway. TQuery + CachedUpdates work decently.
The BDE ODBC bridge works better in this regard. Neither seem to support
anything else than Read Committed as transaction isolation level (at
least I haven't seen differences in behaviour between Read Committed and
Repeatable Read), and you cannot have more that one dataset fetching per
connection (that is: you open a big dataset, then open a small one, and
the BDE fetches all the records from the big dataset before opening the
small one).
Apart from that, applications tend to work, generally. :-)
I have found that ADO (through ADOExpress or dbGo) is a much better
solution; I have limited experience with dbX (I have tested a direct 4rd
party driver which seemed to work decently).
HTH
--
____
_/\/ando
I'll add my two cents here.
> How much of a learning curve is there to move from Interbase to SQLit depends on what use you make of the server. In general, you won't
> Server?
find many missing features, but you may find the general inconsistencies
in SQL Server's design rather frustrating at first.
I'll add to what Daniel said that triggers are executed once per batch
(as opposite to one per touched record as it is in InterBase) and that
transaction control is totally different (ie you can, and in many
instances you must, control transactions in triggers and stored
procedures). This may mean a lot of work depending on your application.
> Does anyone have experience with connecting to a SQL Server databaseThe BDE is not a very viable solution for non trivial SQL Server
> via the BDE? What other connection options are there?
applications.
If you use the "native" driver you are going to have trouble.
Personally, I have never been able to make it work properly with a live
TQuery; the UpdateMode setting is not respected (it always behaves as if
upWhereAll was specified) and it also tries to do pessimistic locking on
edit (I'm not jocking) by issueing a select count(*) when you call the
Edit method. It works with TTable, but it is irrelevant since you are
not going to use TTable anyway. TQuery + CachedUpdates work decently.
The BDE ODBC bridge works better in this regard. Neither seem to support
anything else than Read Committed as transaction isolation level (at
least I haven't seen differences in behaviour between Read Committed and
Repeatable Read), and you cannot have more that one dataset fetching per
connection (that is: you open a big dataset, then open a small one, and
the BDE fetches all the records from the big dataset before opening the
small one).
Apart from that, applications tend to work, generally. :-)
I have found that ADO (through ADOExpress or dbGo) is a much better
solution; I have limited experience with dbX (I have tested a direct 4rd
party driver which seemed to work decently).
HTH
--
____
_/\/ando