Delphi 5 and ADO
Ed Davis
reported with paradox and the BDE? What are the dissadvantages of using
ADO versus BDE? I have done everything that is recommended, but I still
occasionally get the Index out of date errors.
Paul Ferrara
In any event, switching to dBase tables will. The problem is in the
underlying philosophy. Changing drivers won't fix that.
Also, TADODataSet seems to be missing some significant methods, like
SetRange, GotoKey, etc. If you're using TTables, it looks to me like it
would take significant rewriting to make an existing app work with ADO.
Paul / ColumbuSoft
www.columbusoft.com
Ed Davis <eld...@earthlink.net> wrote in message
news:392B11B1...@earthlink.net...
Bill Todd (TeamB)
way to get away from the BDE is to change databases.
--
Bill Todd (TeamB)
(Questions received via email cannot be answered.)
Bill Todd (TeamB)
drivers for SQL Server 7. The BDE SQL Link driver for SQL Server uses
Microsoft's DBLIB.DLL (because that is the way Microsoft said to do it at
the time the driver was written). However, as part of its effort to puch
everyone to ADO, Microsoft has decided not to update DBLIB.DLL to support
SQL Server 7. Since Microsoft has said that ADO is the only data access
technology they plan to support in the future it seems likely that you will
have to convert to ADO sooner or later if you want to use SQL Server.
If you move to a SQL database server, any SQL database server, and you want
good performance you will have to replace all of your TTables with TQuerys.
You will probably also have to change the architecture of your app so users
select a small set of records, do whatever they need to do with those
records, then select another set of records to work with.
Mines
BDE, ADO, ODBC, and Paradox has me a bit confused. I am currently using Paradox
tables with the BDE and Delphi 3.x, that much I know. Now, I am looking into
moving my App into a Client/Server database, particularly MSSQL 7.0. The
question is: I hear people talking about using ADO, or doing away with the BDE
by using a third party BDE replacement such as ODBCExpress, which in turn, makes
reference to the ODBC API. I'll be using Delphi 5.x Enterprise which comes
integrated with the SQL Links for MSSQL 7.0, as you may well know. So, I hear,
I'm still using the BDE for connectivity yet, I have the choice of ADO?. I would
like to know where all these connectivity architectures fall into place with my
future Delphi 5.x/MSSQL 7.0 and which one would be best for me. I also like to
know what should I be concerned with when porting my Delphi 3.x/Paradox App to
the MSSQL 7.0 database. As stated on a previous message, I would be concerned,
if I would have to make any replacements for my current TTables, TQuerys, etc.
and if I would have to change any references to the SetRange and GotoKey methods
on my app to accomodate MSSQL 7.0?
Thanks in advance for your response.
+Mines
"Bill Todd (TeamB)" wrote:
> You cannot use ADO to update a Paradox table without using the BDE. The only
> way to get away from the BDE is to change databases.
>
Mines
MSSQL 7.0, I must use ADO and deal with the issues brought by Paul as:
"TADODataSet seems to be missing some significant methods, like SetRange,
GotoKey, etc. If you're using TTables, it looks to me like it would take
Thanks in advance for your response.
+Mines
"Bill Todd (TeamB)" wrote:
Bill Todd (TeamB)
TTables to a SQL database server backend you will probably have to do some
rewriting. I recently rewrote a large Paradox 7 database system using Midas,
ADO Express and SQL Server 7. The client also had a small inventory system
written in Delphi using TTables against Paradox tables. The largest table
was 8,000 records. I decided to try the cheap approach with that one and
just replaced all of the TTables with TADOTables, changed all the FindKey
calls to Locate and hoped I was done. It was so slow in some areas that it
was totally unusable.
Mines
valuable for those of us who are charting new territory away from Paradox. So I
gather from what you are saying, that MSSQL 7.0/ADO Express combination is a
better alternative in order to obtain speed/performance results on my TTable
Paradox application? Also, have you heard anything positive regarding ODBC
Express? As I understand it. This third party bypasses the BDE and is very
speedy.
Thanks for your response.
+Mines
Mines
> ADO Express and SQL Server 7. The client also had a small inventory system
> written in Delphi using TTables against Paradox tables. The largest table
> was 8,000 records. I decided to try the cheap approach with that one and
> just replaced all of the TTables with TADOTables, changed all the FindKey
> calls to Locate and hoped I was done. It was so slow in some areas that it
> was totally unusable.
I'm sorry Bill, but I am a bit confused now. After responding to your message I
checked the Borland site for ADO Express and realized that the TADOTables that you
mention on your Paradox inventory convertion to MSSQL 7.0(which gave you poor
results), are indeded ADO Express components. What is the difference between the
two projects you mentioned, if they both are using ADO Express??
I guess I don't understand what you mean by using ADO Express if the results are
not going to be good.
Thanks in advance for clarifying this for me.
+Mine
Brian Bushay TeamB
>So I
>gather from what you are saying, that MSSQL 7.0/ADO Express combination is a
>better alternative in order to obtain speed/performance results on my TTable
>Paradox application?
performance but you can also write a poor application that performs worse.
There are other reasons to switch too. A client server backend will give you a
more stable database. Paradox (and BDE) probably are at the end of there
development life so you are not likely to see many improvements. Microsoft is
continuing to aggressively rev and improve MSQL. Client server backends are
also much more scalable then a networked database like Paradox.
>Also, have you heard anything positive regarding ODBC
>Express? As I understand it. This third party bypasses the BDE and is very
>speedy.
I have used ODBC express and I and it has worked very well in the applications I
have used it for. It does not need BDE but you do have to have the ODBC driver
you want to use installed on every machine you want to use the application on.
If I needed to create an application that could use different database backends
this would be my database tool of choice. However If I know that I would be
using MSQL I would go with an ADO component because the support for MSQL is very
good and I expect that MS development will give its highest priority for future
development of its database to work with ADO.
--
Brian Bushay (TeamB)
Bbu...@NMPLS.com
Brian Bushay TeamB
>I'm sorry Bill, but I am a bit confused now. After responding to your message I
>checked the Borland site for ADO Express and realized that the TADOTables that you
>mention on your Paradox inventory convertion to MSSQL 7.0(which gave you poor
>results), are indeded ADO Express components. What is the difference between the
>two projects you mentioned, if they both are using ADO Express??
>I guess I don't understand what you mean by using ADO Express if the results are
>not going to be good.
The TADOtable is one of the components in ADOExpress. It is intended primarily
as an easy replacement in existing applications for a Ttable. To understand
why it did not work well in Bill's application you need to understand some of
the differences between using a networked database like Paradox and a client
server backend like MSQL.
When you create a Paradox application and you connect a large table to a Ttable
you can create an application where you let the user browse through all the
records in the database. Paradox performs this kind of access very well.
SQL back ends do not browse tables well. With an SQL backend you need to set it
up so that it fetches a small number of records which it is very efficient at.
What the TadoTable does when you open it is read all of the records in the table
it is connected to into memory. Once the records are in memory access is very
fast but there is a big performance hit opening the table and reading all the
records.
The better alternative is to use a TadoDataset and set up the appliction so that
it provides and SQL statement to the client server backend that will return a
limited number of records.