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

Mon May 29 13:20:02 NZST 2006

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
>>>>> 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
>>
>>
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi