All geek questions in one place

Connecting Delphi to SQL Server - Replacing the “Future Future” for BDE?

we have an application of a certain size (about 1MLOC) that was launched back in the days when BDE was about to become obsolete. Currently, we only use it to connect to SQL Server using ODBC. It worked surprisingly well, despite its outdated status, and most likely it will continue to work for another 15 years. However, no one knows if it stops or stops working. And if he stops, Embarcadero cannot do much. So this is a temporary bomb, and we need to replace it. But with what?

Delphi's ADO components look promising. There are table and query components that resemble BDE components, and they are not third-party components created by a single-person store that might lose interest. We also expect to use connection strings instead of the clumsy ODBC administrator.

However, about a year ago, Microsoft announced that OLE DB was deprecated, and for development in the native language, we must use the ODBC driver of SQL Server's own client.

So my question is, are ADO components in Delphi related to OLD DB? Or will we not use OLE DB if we select "SQL Server Native Client" in the driver list?

I expect / fear that in order to use the ODBC driver of our own SQL Server, we must configure the data source in ODBC-Adminstrator, as now. Or can you connect to ODBC using connection strings?

And what are the Delphi components that can connect to ODBC without using OLE DB? Yes, I know about dbExpress, but it looks like it will take us years to convert it from BDE.

Thanks Landshark

+4
source share
3 answers

We had a similar migration 5 years ago, and he conducted a lot of research and testing. The easiest migration path from BDE is the devart SDAC (http://www.devart.com/sdac/). Devart has a BDE replacement utility that goes through your code and replaces the BDE components with equivalent SDAC components. This will give you about 90% of the way, then you will have to manually make some changes to make everything work (for example, if you use fetchall, you need to comment out all the fetchall code, but you will see the template and you can fix the remaining code mainly by searching and replacing) . The performance of the SDAC components is excellent, they support all sql server calls, and you can use encrypted connections over the Internet. Components support Native SQL or OLEDB connections to SQL Server. They also work offline using cached updates. Another option, if you plan to support other database platforms in addition to the SQL server, is to use UniDac - this is exactly the same as SDAC, but it will work with SQL Server, Oracle and others - very similar to the old BDE without overhead.

+3
source

1) “native connection” does not mean using ODBC or OLE DB, neither BDE nor DBX. Native connection means using a special library that can only connect to MS SQL and which does not use standard server agnostic pipelines. In contrast, BDE and DBX, as well as ADO and ODBC, are shared libraries that provide connections to any server for which you must install the plugin.

In general, native libraries provide closer integration with the server and use of some functions that may not be available in shared libraries (for example, events on firebird / interbase servers). They can also work faster because they do not need to transcode data streams and commands to / from the public API standards for the pipeline.

The public OTOH interfaces help you with easier server switching and simplify the development of a server-agnostic application.

2) Why do you think that converting BDE → DBX would be more complicated than BDE → ODBC or BDE → ADO or BDE-> anything? A transformation is a transformation. ADO also has its share of limitations and gets like DBX and like any other library.

3) DBX has an MS SQL plugin. DevArt offers its own version of DBX plugins and can provide better support than Delphi DBX MS SQL support. Or maybe not.

4) In addition to those that have several well-known server-agnostic libraries

5) you can have a lot of direct ODBC connections on any component builder site, for example http://www.torry.net/pages.php?id=570

6) the same for the native MS SQL link http://www.torry.net/pages.php?id=1513

However, evaluating these options and making your decision requires within-context knowledge that you can only have.

+2
source

We had the same problem a few years ago. I believe that if there was an ideal solution, then there would not be many alternatives.

In any case, we switched from BDE + ODBC to ADO + SQLOLEDB. The main reasons were that it was very reliable, easy to use, did not require the installation of any additional components on client computers (for example, BDE), and was faster than others supplied with delphi, including DBX (when using DisableControls) .

Also as a side note, if you want to use ODBC to configure the connection, you can use the ODBC manager to configure the values, but read them from the registry and connect directly without ODBC. This helped us make the switch.

0
source

Source: https://habr.com/ru/post/1439147/

More articles:


All Articles