Board index » delphi » Effort to move from BDE to ADO ?

Effort to move from BDE to ADO ?

Hi All!

Is a big effort to move from BDE to ADO ?

Theoretically, it should not be to much difference... A TADODataSet
that replaces a TBDEDataSet, or am I wrong ?

Does ADO work better than BDE as a general observation ?
(I'm using SQL Server 7, and I am sure ADO works better for that.)

Thanks!
/sten

 

Re:Effort to move from BDE to ADO ?


Quote
> Is a big effort to move from BDE to ADO ?

Not as easy as I thought.  Some of the error messages are quite bizarre, eg
Catastrophic Failure.

Quote
> Theoretically, it should not be to much difference... A TADODataSet
> that replaces a TBDEDataSet, or am I wrong ?

No - you are right.

Quote
> Does ADO work better than BDE as a general observation ?
> (I'm using SQL Server 7, and I am sure ADO works better for that.)

Well like using ODBC (or even BDE) it depends on the quality of the driver.
However, as you say, it is definetely better for SQL Server 7.

Oliver

Re:Effort to move from BDE to ADO ?


Hi Sten,
I recently completed converting a major app (200+ data access controls,
600,000 lines of code, SQL7) from BDE to ADO.  While it was quite a bit of
work, it was not daunting.  It took approximately two weeks of serious
detail work... you might call it "grunt" work, but the results were great.
I have experienced close to 50% faster data access and replication works
like a charm with ADO.  Make sure you have the programming resources
available if you make the decision to move, and be patient.  A lot of the
parameters have changed, and getting used to ADO is going to be strange...
Sort of like the first app you ever wrote for the BDE.  All in all I have to
give Inprise high regards for their implementation of ADO... best of all, it
*works*
Regards,

Ron

Quote
Sten Larsson <s...@xdin.com> wrote in message

news:tn6nOCMybig0CQ0NxK2QhNNhD6d2@4ax.com...
Quote
> Hi All!

> Is a big effort to move from BDE to ADO ?

> Theoretically, it should not be to much difference... A TADODataSet
> that replaces a TBDEDataSet, or am I wrong ?

> Does ADO work better than BDE as a general observation ?
> (I'm using SQL Server 7, and I am sure ADO works better for that.)

> Thanks!
> /sten

Re:Effort to move from BDE to ADO ?


Hi Sten,
I recently completed converting a major app (200+ data access controls,
600,000 lines of code, SQL7) from BDE to ADO.  While it was quite a bit of
work, it was not daunting.  It took approximately two weeks of serious
detail work... you might call it "grunt" work, but the results were great.
I have experienced close to 50% faster data access and replication works
like a charm with ADO.  Make sure you have the programming resources
available if you make the decision to move, and be patient.  A lot of the
parameters have changed, and getting used to ADO is going to be strange...
Sort of like the first app you ever wrote for the BDE.  All in all I have to
give Inprise high regards for their implementation of ADO... best of all, it
*works*
Regards,

Ron

Quote
Sten Larsson <s...@xdin.com> wrote in message

news:tn6nOCMybig0CQ0NxK2QhNNhD6d2@4ax.com...
Quote
> Hi All!

> Is a big effort to move from BDE to ADO ?

> Theoretically, it should not be to much difference... A TADODataSet
> that replaces a TBDEDataSet, or am I wrong ?

> Does ADO work better than BDE as a general observation ?
> (I'm using SQL Server 7, and I am sure ADO works better for that.)

> Thanks!
> /sten

Re:Effort to move from BDE to ADO ?


You say you are using replication. What kind of scheme are you using? Do you
have several disconnected sites that get updated periodically? If so, do you
use a site ID?

--
Alain Quesnel

P.S. : Remove the sans spam in my address to reply by e-mail

Ron Brown a crit dans le message <889g03$i...@bornews.borland.com>...

Quote
>Hi Sten,
>I recently completed converting a major app (200+ data access controls,
>600,000 lines of code, SQL7) from BDE to ADO.  While it was quite a bit of
>work, it was not daunting.  It took approximately two weeks of serious
>detail work... you might call it "grunt" work, but the results were great.
>I have experienced close to 50% faster data access and replication works
>like a charm with ADO.  Make sure you have the programming resources
>available if you make the decision to move, and be patient.  A lot of the
>parameters have changed, and getting used to ADO is going to be strange...
>Sort of like the first app you ever wrote for the BDE.  All in all I have
to
>give Inprise high regards for their implementation of ADO... best of all,
it
>*works*
>Regards,

>Ron

>Sten Larsson <s...@xdin.com> wrote in message
>news:tn6nOCMybig0CQ0NxK2QhNNhD6d2@4ax.com...
>> Hi All!

>> Is a big effort to move from BDE to ADO ?

>> Theoretically, it should not be to much difference... A TADODataSet
>> that replaces a TBDEDataSet, or am I wrong ?

>> Does ADO work better than BDE as a general observation ?
>> (I'm using SQL Server 7, and I am sure ADO works better for that.)

>> Thanks!
>> /sten

Re:Effort to move from BDE to ADO ?


Oliver,

thanks for your response!

/sten

Re:Effort to move from BDE to ADO ?


Hi Ron,

thanks for your reply. I'm getting more convinced that I shall do the
transition as soon as possible.

/sten

Re:Effort to move from BDE to ADO ?


The way we're handling replication is sort of odd.  The NT Server is
actually on a card plugged into an AS400.  Since the AS400 goes down nightly
for backup, the NT Server naturally goes down as well.  The NT Workstation
is in a 24/7 production environment, so the DB needs to be available at all
times.  Of course, the customer wants the data to reside on the Server, so I
set the Workstation up as a producer/distributor for Merge replication and
set up a pull subscription on the Server.  Whenever the Server is up, it
periodically pulls new records/changes from the Workstation.  We are not
using a site ID as all involved computers are members of the same domain.

Regards,
Ron

Quote
Alain Quesnel <alainsanss...@argosoftware.com> wrote in message

news:88aqqg$j0210@bornews.borland.com...
Quote
> You say you are using replication. What kind of scheme are you using? Do
you
> have several disconnected sites that get updated periodically? If so, do
you
> use a site ID?

> --
> Alain Quesnel

> P.S. : Remove the sans spam in my address to reply by e-mail

> Ron Brown a crit dans le message <889g03$i...@bornews.borland.com>...
> >Hi Sten,
> >I recently completed converting a major app (200+ data access controls,
> >600,000 lines of code, SQL7) from BDE to ADO.  While it was quite a bit
of
> >work, it was not daunting.  It took approximately two weeks of serious
> >detail work... you might call it "grunt" work, but the results were
great.
> >I have experienced close to 50% faster data access and replication works
> >like a charm with ADO.  Make sure you have the programming resources
> >available if you make the decision to move, and be patient.  A lot of the
> >parameters have changed, and getting used to ADO is going to be
strange...
> >Sort of like the first app you ever wrote for the BDE.  All in all I have
> to
> >give Inprise high regards for their implementation of ADO... best of all,
> it
> >*works*
> >Regards,

> >Ron

> >Sten Larsson <s...@xdin.com> wrote in message
> >news:tn6nOCMybig0CQ0NxK2QhNNhD6d2@4ax.com...
> >> Hi All!

> >> Is a big effort to move from BDE to ADO ?

> >> Theoretically, it should not be to much difference... A TADODataSet
> >> that replaces a TBDEDataSet, or am I wrong ?

> >> Does ADO work better than BDE as a general observation ?
> >> (I'm using SQL Server 7, and I am sure ADO works better for that.)

> >> Thanks!
> >> /sten

Re:Effort to move from BDE to ADO ?


Hi!
We recently converted a 100 table, 300,000 rows of code app from BDE
(Paradox) to ADO (SQL Server 7). We have had some trouble, but far less than
we had expected.

I think the easiest way is to firt replace the BDE components with the
near-compatible ones. We did it this way. After converting everything this
way we took a closer look at the "slow code". Using TADOCommand (with no
recordSet) is a magnitude faster than using for example TADOQuery. You get
the real speed when usin the TADOCommand with stored procedures.

Here are some of the issues we had:
- Paradox queries uses " for string delimiter, SQL Server uses '
- Paradox joins does not demand typing of tablename, SQL server says
"ambigous use..."
Paradox example:
Select TableA.Field1, TableB.Field2 from TableA
join TableB on (TableA.Id = TableB.Id)
Where Field2 = "ABC"

Same example in SQL Server 7:
Select TableA.Field1, TableB.Field2 from TableA
join TableB on (TableA.Id = TableB.Id)
Where TableB.Field2 = 'ABC'      <-- have to type TableB.Field2

- ParamByName is moved from directly under TQuery to
TADoQuery.parameters.paramByName so you have to add .parameters to all of
your paramByname calls.

- IMPORTANT!  FindKey is gone. You have to use locate instead which
performes a sequential search instead of a binary one. If you have a lot of
FindKey (We had), the app will run much slower because of the bad behaviour
of locate. Well... the locate thing does not fit in with a Client/Server
sollution, I know. But findKey is a powerful thing in Paradox.

I traced the bahaviour of locate and found out that it performs a sequential
search. SQL servers cursor function has the ability to jump to absolute
positions in a dataset so I wonder why Borland didn't implement locate as a
binary serach method.

- Turbopowers reportView...
Fortunately we hadn't begun using this component yet. It does not support
wideStrings. All strings in ADO are WideStrings.

Hope it helped.
Sincerely, Michael Sageryd

-- Sorry, the following is in Swedish ---
Sten, kontakta mig g?rna p? m[no]@[spam]ws.se. Ta bort nospam f?rst. Det ?r
alltid bra att ha kontakt med utvecklare som jobbar med liknande saker s? vi
kan s?kert hj?lpa varandra. file://Micke
---------------------------------------

Quote
Sten Larsson <s...@xdin.com> wrote in message

news:tn6nOCMybig0CQ0NxK2QhNNhD6d2@4ax.com...
Quote
> Hi All!

> Is a big effort to move from BDE to ADO ?

> Theoretically, it should not be to much difference... A TADODataSet
> that replaces a TBDEDataSet, or am I wrong ?

> Does ADO work better than BDE as a general observation ?
> (I'm using SQL Server 7, and I am sure ADO works better for that.)

> Thanks!
> /sten

Other Threads