Hi Friends

Hi Friends,

Is there any chance to insert records in paradox table using ADO controls ?

Because i am trying on that and getting errors with Table, Dataset and Command as well.

I am using Delphi 2006, its working fine with TTable however we want to move to XE8 and TTable is not supported on that i think.

Any help is appreciated.

Comments

  1. BDE is a separate download now, from Emb's registered user download page. However, moving away from it is long overdue. :)

    ReplyDelete
  2. I'd go directly to FireDAC, instead of ADO.
    We recently migrated, and the performance and robustness of FireDAC is miles ahead of ADO

    Edit: We did an MS SQL Server centric port.

    ReplyDelete
  3. Thanks for your input Eivind Bakkestuen  and Lars Fosdal , OK let me try with sample application for FireDAC, We are not moved to XE but we are planning to do that.

    ReplyDelete
  4. For performance, yes, FireDAC can be years ahead of ADO, but how can it be more robust that something that does not fail, EVER?
    I've created more than a dozen huge applications in my previous job. All running 24x7 in very demanding scenarios. They keep running for 15+ years now. Created with Delphi 3, and migrated to Delphi 5, then 6, then 2006 and finally XE+. They are all ADO based and I can tell you: ADO does not fail. If the application fails, it is your code, not the ADO layer.
    Besides that, there is a hidden advantage of ADO over almost all other stuff out there: You NEVER have to migrate to a newer Delphi/DB framework version/DB engine version/Whatever just because your OLD DB framework does not support your NEW version of the RDBMS server, something that you guys that worked with BDE + ORACLE know well. The producer of the RDBMS (Oracle, Microsoft, etc) also produces the OLE DB provider that ADO uses to communicate with the DB server. So you can always work with latest versions of all DB servers out there.

    ReplyDelete
  5. Alexandre Machado ADO is tried and stable - but if migrating from BDE, ADO would not be my framework of choice.  FireDAC uses the same ODBC native drivers that ADO will use, so you will have the same resilience against version upgrades as ADO does.

    One of the things that was very pleasurable with FireDAC: ADO won't reconnect if you lose IP connection to the DB. It will take it's time to time out and then raise an exception, even if the connectivity has been restored. FireDAC reconnects seamlessly.

    ReplyDelete
  6. I'm not sure if you are talking about ODBC drivers or OLEDB providers. ADO does not use ODBC drivers, but OLEDB providers. They are different. Although it can also connect through ODBC drivers using a special provider named MSDASQL.. But this usually only happens when dealing with legacy DBs

    ReplyDelete
  7. On another note - MS is abandoning OLEDB, but keeping ODBC - which also is a good argument for skipping ADO.

    ReplyDelete
  8. You mean that MS is abandoning OLEDB providers for their OWN product, SQL Server, not the OLEDB layer. And for now, they said they will keep its support for at least 7 years. It does not mean that OLEDB as a technology is also deprecated. This was never said by MS.

    ReplyDelete
  9. Valid point. We are MS SQL centric, so I guess that's my bias kicking in.  But again - if migrating from BDE, I would definitively encourage considering FireDAC before ADO.

    ReplyDelete
  10. I agree with you in this case. But I should note that, if I needed any MS tech to last more than 7 years, I would be programming in Linux! :-p

    ReplyDelete

Post a Comment