I haven't got that far yet - there appears to be one provided wit D2006 - According to the blurb.
This may not be the case I haven't actually opened up the box and installed... That is the plan for
tomorrow. I have heard CoreLlib provides one, supposedly good - but I really don't want to get into
supplying another vendors components - we have been through that several times (problematic).
I would prefer to just use what is provided as "bog standard" by Delphi!
The biggest issue we are going to have is that we are changing 4 Apps + all reporting (100's or
reports). The Apps range from small (probably only a week or two to migrate) to large with 1000's of
SQL statements, mostly on the server but there are a lot created dynamically on the client and
passed through.
I am finding that DBExpress was considered buggy/unstable and ADO was the way to go, but this
appears fixed and we could now (D2006) go with either...
Regards
Paul McKenzie
Wellington
New Zealand
Neven MacEwan wrote:
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
_______________________________________________
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
