[DUG] Migration from IBX to Interbase to SQL-Server 2005

Mon May 29 13:07:06 NZST 2006

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
>>>> Delphi at ns3.123.co.nz
>>>> http://ns3.123.co.nz/mailman/listinfo/delphi
>>>
>>>
>>> _______________________________________________
>>> Delphi mailing list
>>> Delphi at ns3.123.co.nz
>>> http://ns3.123.co.nz/mailman/listinfo/delphi
>>>
>>>
>>
>> _______________________________________________
>> Delphi mailing list
>> Delphi at ns3.123.co.nz
>> http://ns3.123.co.nz/mailman/listinfo/delphi
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: neven.vcf
Type: text/x-vcard
Size: 164 bytes
Desc: not available
Url : http://ns3.123.co.nz/pipermail/delphi/attachments/20060529/1aa14917/neven.vcf