Paul
> not sure what a client side static dataset is ? is this a ClientDataSet ?
Basically yes, ADO is a big fat 'thing' that attempts to do much of what
TClientDataSet and TDataSetProvider do, but it does it badly, mainly
because you have little control over what it does (esp when it trys to
apply updates), Now if you are only using it to provide data and you are
resolving the updates yourself (or in your app lib) then there is little
point in many megabytes of MDAC being used
Comparing ADO and dbExpress is like comparing an Elephant with a
Whippet, yes you can take the elephant for a walk but it hurts a sh%t
load more if it stands on your foot
ps which dbExpress providor for MSSQL are you looking at?
Neven
Paul McKenzie wrote:
We are using (and will use) TClientDataSet's on the Client and
TDataSetProvider's on the AppServer. The TDataSetProvider will connect
to T???Query and T???StoredProc Components (in almost all cases).
I found this from Brian Bushay - TeamB
"dbExpress is faster for working with SQL Server than ADO
However ADO is better adapted to SQL server so it is easier to work with."
not sure what a client side static dataset is ? is this a ClientDataSet ?
We do all sorts of weird and wonderful things with our data and datasets
on both the client and server - many of them would make one wonder, why
the f*#k would you do that or do it like that :-)
It is a lot of legacy code...
Regards
Paul McKenzie
Wellington
New Zealand
Neven MacEwan wrote:
Paul
Simply from a risk point of view i'd veer toward DBExpress from
ADOExpress, I found ADO incredibly frustrating and would have used
DBExpress if there was a driver available at the time, Things to watch
with ADO is the performance of any server side dataset (in fact only
client side static datasets are useful!) I got to the point where I
read into memtables and wrote my own resolver! But as I said it
depends on how you are treating your db and what you expect/want your
dataset to do
HTH
Neven
Paul McKenzie wrote:
The Conversion from InterBase to SQL-Server is not the problem. We
have tools and experts to do that.
The issue we have is that we need to migrate our 3-Tier App from IBX
components to DBExpress or ADOExpress - We are investigating which is
best...
The appear to be fairly equal!
I was wondering if anyone had done the conversion (or similar
investigation) and found it easy to go to one but not the other. Or
found one cannot do something vital etc.
One big issue is that we would like to migrate to SQL-Server 2005 and
will probable move to D2006 for this but are having to investigate
this as well.
One big issue we had (this is very legacy code) is that the IB
optimiser was killing our SQL in many heavy-duty frequently used
cases... we had to re-write our SQL just to force InterBase to not
optimise and thus run much faster (in most cases speed reduced from
many minutes to a few seconds)
Everything I have read so far (ok 0.5 a day) indicates that DBExpress
vs ADOExpress is just preference!
Hoping someone has had experience...
The only indicator is from the Newsgroup "SQL Servers - May 2006"
Bill Todd (TeamB) recommends ADO over DBExpress for Win32!
Regards
Paul McKenzie
Wellington
New Zealand
Neven MacEwan wrote:
Paul
I haven't done this but you may be able to use xCase
(www.xcase.com) to rev engineer your existing database and then set
it up on SQL-Server 2005. As for the 'best components' for SQL It
would depend on how you are using your existing db? Tables, queries,
stored procs from your statement "We know we will have to re-visit
all the SQL for syntax and probably for performance" in theory not
but the devil is in the details
Are you using RI? is so how? The biggest issue is in the functions
/stored procs/trigger code ie the specific scripting code for the db
HTH
Neven
Paul McKenzie wrote:
We are considering migrating several Win32 (D7) 3-Tier apps from
IBX/Interbase to SQL-Server 2005.
The Apps all access the same large Database - The apps range from
small to very large.
What are the best components to use for SQL Server ?
What are the difficulties/gotchas in migrating ?
Any good links and/or best practices for migration ?
We know we will have to re-visit all the SQL for syntax and
probably for performance.
Are there any issues, we would probably not see until the end, that
we need to look out for ?
Any Help much appreciated...
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
--
Neven MacEwan (B.E. E&E)
Ph. 09 620 1356 Mob. 027 4749 062
New Address Details
===================
MWK Computer Systems
1 Taumata Rd
Sandringham
Auckland
Ph 620 1356
Fx 620 1336
begin:vcard
fn:Neven MacEwan
n:MacEwan;Neven
email;internet:[EMAIL PROTECTED]
tel;work:649 620 1356
tel;fax:649 620 1336
tel;cell:0274 749 062
version:2.1
end:vcard
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
