we have an applcation of some size (about 1MLOC) that were started back in the days when BDE was just about to be deprecated. Nowadays we only use it to connect to SQL Server using ODBC. It has worked surprisingly well in spite of its deprecated status, and chances are it will keep on working for another 15 years. However, no one knows if or when it stops working. And if it stops, Embarcadero wouldn't be able to do much about it. So, it's a timebomb, and we need to replace it. But with what?
The ADO-components in Delphi looks promising. There are table and query components that resembles the BDE-components, and they are not third-party components made by a one-man shop that might loose interest. We also look forward to use connection-strings instead of the clunky ODBC-Administrator.
However, about a year ago Microsoft announced that OLE DB is deprecated, and for native development we should use SQL Server Native Client ODBC driver.
So, my qestion is, is the ADO-components in Delphi hardwired to OLD DB? Or would we not be using OLE DB if we select "SQL Server Native Client" in the list of drivers?
I expect/fear that to make use of the SQL Server Native Client ODBC driver, we have to set up a datasource in ODBC-Adminstrator, like we do now. Or is it possible to connect with ODBC using connection-strings?
And what Delphi-components exists that can connect to ODBC without using OLE DB?
Yes, I know about dbExpress, but it looks like it would take us years to convert to it from BDE.
Thanks,
LandShark
We had a similar migration need 5 years ago and did quite a bit of research and testing on it. The easiest migration path from the BDE is to SDAC from devart (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. It will get you about 90% of the way there then you have to manually make some changes to get everything to work (e.g., if you use fetchall, have to comment out all the fetchall code - but you will see a pattern and can fix the remaining code mostly through search and replace). Performance of the SDAC components is excellent, they support all the sql server calls and you can use encrypted connections over the internet. The components support Native SQL or OLEDB connections to SQL Server. They also work in detached mode using cached updates. Another option, if you plan on supporting other database platforms in addition to SQL server is to use UniDac - it's just like SDAC but will work with SQL Server, Oracle and others - very similar to the old BDE without the overhead.
1) "native connection" does not mean use of ODBC or OLE DB, nor BDE and DBX. Native connection mean using special library that only can connect to MS SQL and that does not uses any standard server-agnostic pipileines. Contrary BDE and DBX and ADO and ODBC are generic libraries providing connection to any server you'd install plugin for.
Generally native libraries provide you closer integration with server and use of some features that generic libraries may miss (like events in firebird/interbase servers). They can also work faster for they do not need to transcode data streams and commands to/from the pipeline public API standards.
Public interfaces OTOH aid you with easier switch of servers and easier development of server-agnostic application.
2) Why do you think that BDE -> DBX conversion would be any harder than BDE -> ODBC or BDE -> ADO or BDE-> whatever ? The conversion is the conversion. ADO also has its share of limitations and gotcha's like DBX and like any other library.
3) DBX have MS SQL plugin. DevArt offers their suit of DBX plugins and may provide better one than stock Delphi DBX MS SQL support. Or maybe not.
4) Aside of those there are few well-known server-agnostic libraries
ZeosLib - FLOSS but have poor support for recent Delphi versions. Eternal alpha.
AnyDAC - http://www.da-soft.com/anydac , commercial, well-known
UniDAC - http://www.devart.com/unidac , commercial, well-known
5) you can have a lot of direct ODBC connection on any component collector site like http://www.torry.net/pages.php?id=570
6) same for native MS SQL connectivity http://www.torry.net/pages.php?id=1513
However, evaluating those choices and making your decision requires inside context knowledge that only you can have.
We had the same problem a few years ago. I suppose if there would be a perfect solution then there wouldn't be that many alternatives.
Anyway, we switched from BDE + ODBC to ADO + SQLOLEDB. The main reasons was that it was very reliable, easy to convert, didn't require anything extra to be installed on customer computers (such as BDE) and was faster than others shipped with delphi, including DBX (when using DisableControls).
Also as a side remark, 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. That helped us to do the switch.
Related
I'm looking for a way that I can keep a database in one single file, no server hosting it, and with the ability to use ADO (In delphi, specifically TADOConnection and/or TADOQuery). Please pardon my lack of terminology on this one. I'm only familiar with SQL Server databases, and nothing about any others. In fact, the only other ways I know to read/write files are Plain Text, INI, and XML. As for any official "databases", I know nothing.
So what I would like to do is keep a single file as a database, similar to how QuickBooks has a single "Company File". I should not have anything to host the data, such as SQL Server. And it needs to be compatible with ADO, so I can use simple select, update, delete, etc. It doesn't need to be so complex as to have relations, security, etc. But it does need to have some same syntax rules as SQL Server, like commands such as join, alter, distinct, etc.
I'm looking for the lightest-weight method to do so. The files need to be flexible enough to be able to copy/paste (so long as the application isn't using it), similar to an excel file. In fact, my original idea was to use Excel, as I know I can use ADO, but I also don't want to require Microsoft's excel drivers (it would have to presume that MS Office / Excel is installed on user's computer). It's obviously going to need some drivers, but I need the most standard method which is compatible everywhere.
You can use MS-Access MDB files. It can be used via Microsoft OLEDB Jet 4 engine (Which is build in into Windows since at least Win XP) and is perfect for local desktop DB applications, with the ability to create Tables, PKs, Indexes, Queries/Views, Transactions, Multi-User, replication, compact/repair and much more with almost perfect compatibility to MS SQL-Server SQL syntax (since MS-Access is the ancestor of MS SQL-Server).
MS-Access product (i.e MS Office) dose not have to be installed on the client machine.
No extra drivers or files to install, and completely integrable with existing MS-Office products.
Edit: MDB files could be also Protected/Encrypted.
You have several options for store your data in single database file.
SQLite
Firebird
Interbase
All of them can be accesed via ADO using a ODBC or OLEDB driver. my personal recomendation is Firebird, because is free, fast, stable and had a Embedded version.
This is a pretty useful comparison of a number of embedded databases. Of the ones tested these ones support (odbc), (oledb) or (both) and use a (single) file for the database:
Accuracer (odbc) (single)
NexusDB (odbc) (single v4 and newer)
Firebird (both) (single) - multiple odbc implementations and the commercial IBProvider supports three different ways to connect to the ADO components.
TurboDB (odbc) (single v4 and newer)
Note: Most of these also supply ADO.Net Providers as well.
The other's in the comparison (Advantage, ElevateDB, DBISAM and Apollo) use a file per table/index scheme.
When looking for which version of Delphi 2010 to buy, we found the following limitation on the professional one:
Delphi 2010 Professional is designed
for developers building
high-performance desktop GUI and
touch-screen applications with (or
without) embedded and local database
persistence.
What does this really mean? Does this mean that we'll only face this restriction if we choose to use the native vcl components for database access we'll face this restriction.
And what if we choose to use ADO components instead of those? In this case, how can Delphi avoid us to access remote database servers? Did anyone here ever tried this?
Going even further: if we choose to use a database like Firebird, which is just one file, and used a network mapped drive. Could we be facing the same limitation?
Supposing we opt for ADO, what will be the main consequences?
As I understand it, they're referring specifically about dbExpress and doesn't restrict you from using dbGo or some third party library to access remote databases.
Does this mean that we'll only face
this restriction if we choose to use
the native vcl components for database
access we'll face this restriction.
Yes. The professional version simply leaves out some of the driver & driver technology that natively supports certain databases. It still includes ADO support and there are plenty of third-party drivers that you can use to access other databases.
Delphi 2010 does not include any technology to stop you from building applications that interact with remote databases aside from the fact that it does not include DB Express (its own database driver technology).
DataSnap is not included in the Pro version either. I got quite interested at a recent Delphi workshop when they showed off DataSnap only to discover when I got back that it's missing from the Pro version.
So I'm back to sticking with my SDAC components and other third party middleware components. Works perfectly without the expense of the enterprise version.
The SQL Server dbExpress driver isn't included (amongst others) but the ADO/dbGo stuff seems to work just fine over the network. But we haven't used the Delphi supplied DB drivers since Delphi 3 due to them keep changing their mind about the latest silver bullet for DB access (much like MS do/did).
I found this question here: OLEDB v/s ODBC
Which gave me more information, but did not really answer the question I'm asking, so I shall proceed from there.
I am working in C#. I'll spare you the long story about how I arrived at this conundrum, but basically I'm trying to decide between ODBC and oleDB.
We work with a lot of different clients who have vastly varied Databases (some SQL, some oracle, some something else that I've never heard of and didn't bother to remember the name of)
Now, from what I understand, ODBC is old, and was/is the standard. And now OleDB has come along and... is... different? but accomplishes the same thing (it talks to databases)
Why would I want to use one over the other? ODBC is (according to the above post) cross-platform, which is good, but he offers very little information as to what OleDB offers that ODBC does not.
In my other research, I've found (on the MSDN forums) People saying "use OleDB if you can, if you have to, resort to ODBC" Naturally, three's no reasoning given for this, so I'd like to hear some.
ODBC is a C API for accessing databases. There is a standard for it, it is supported by every major database vendor, it is very well documented, it is cross-platform. OLEDB is a similar interface that uses Microsoft's COM technology instead of the C API. This means that it is only easily useable on platforms that support COM.
At the end of the day, both libraries provide roughly equivalent basic functionality. Indeed, Some OLEDB drivers actually make use of ODBC rather than native database libraries.
So, if you are C# developer, working on Windows, OLEDB is the obvious choice between the two. If you are using C (or C++ not using COM), or need cross-platform support, then ODBC is the better bet.
As a C# developer and because you are accessing many different datasources you should go with OLEDB. I copied the following from this white paper because it gives some hints what to use when:
OLE DB is Not a Replacement for ODBC
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
If you are programming in an OLE environment, OLE DB is the best choice.
If want to build interoperable database components, OLE DB is the only choice.
If you're programming in C#, you will not directly use either one. You'll use ADO.NET in some form.
True, the provider that you specify in your connection string may turn out to be an ODBC provider or an OleDB provider, but this will not matter to your code. ADO.NET will both APIs from your view.
Which of the Database servers would you people recommend for using in a moderate-to-large scale (will vary from customer to customer) application.
I know MS SQL but since the app will be developed using delphi the .net framework is kind of annoying to deploy aswell. Also how realiable is Interbase.
Thanks in advance.
Since I have been developing in Firebird for several years now, if I were in your situation, I would look no further. The fact that you can develop your own extension library (udf library) in Delphi makes it very attractive to start with. Some of the new SQL constructs like the List aggregator and Common Table Expressions are icing on the cake. Deployment is very light (under 5 MB), and the support is excellent including incredible tools like IBExpert. I used MS SQL Server in a big company I worked at a few years ago and I would choose Firebird over MS SQL Server.
Data Access to SQL Server has nothing to do with the .NET framework. Delphi can connect just fine to SQL Server.
In terms of database engines that work with delphi, another you can consider is the Sybase Advantage Database server
Interbase is as reliable as they come. In fact, I'd like to get a job as an Interbase DBA, because I could uses the sleep.
I would definitely recommend looking at Interbase by Embarcadero or the open-source sibling, Firebird. Both are very well supported by Delphi by means of native, high-performance db-access components and such.
Interbase is a totally rock-solid database - I would put it on a par with SQL Server or Oracle. It's totally capable of handling medium to high traffic for at least 50-100 users concurrently, no problem at all.
Another two worth competitor would be Elevate DB and Nexus DB. Both grew out of Delphi file-based database systems, and both have been around for quite some time (in one form or another) and are well proven, widely used, well tested.
Marc
This seems back-to-front to me. I would choose the database server first, then select the development environment that works best with the selected database.
SQL Server. For 2005, you can make your own SQL Server deployment application that automates installing of Windows Installer 3.1, .NET Framework 2.0, SQL Server 2005 then installing the database through generatated SQL script (Feel free to contact me if you need help with it, I'd gladly help you). If you still insist on not installing .Net framework which is 22MB, I'd say go with SQL Server 2000 as you can still upgrade it to 2005+ when you'd like to.
Also, I had been using Advantage Database Server for few years and it's alright, Few DLLs to copy and you're ready to go even if you'd like to switch to remote version.
Both Server and Client installations of MS SQL require the .NET framework on the target machine. That's about it. If we can use ms sql without .net on target machine then ms sql is fine.
I have being developing in Delphi for about 6 years using distinct editions of SQL Server, and this database server behaved very very well. All of them were critical applications.
So, I would recommend you to keep with it.If you don't want to use .NET with and keep SQL Server I would recommend an older version pre-2005.
This isn't really an answer, but some things you might like to consider before making your mind up.
What do you mean by moderate-to-large scale? Do you mean by the number of concurrent users or by the amount of data being stored?
Are you going to be supporting the database as well when it's deployed, or might the customer have their own DBAs and want to incorporate it into their infrastructure team's remit?
Do you need to build-in complex features like auditing or granular security that some databases might provide out-of-the-box? Do you need to be able to run an overnight batch process on the database in some controlled manner?
Do you need to be able to have robust high-volume transactional support, or is it more for just using as a sink for reporting data? i.e. is it more OLTP or OLAP?
Are you limited by cost? i.e. does it need to be free/open-source, or can you select paid-for vendor product?
Both Firebird & Interbase are great, but not generally well-received into an "enterprise" environment in my experience unless they're "hands-off" and embedded into the application. MS SQL Server is a "safe-bet" for most systems. There is a cost associated with it but, as you know, it does come with a complete toolset and very good support.
If you do go down the Firebird or Interbase route then do take a look at Jason Wharton's IBObjects library which provides a high-performance replacement for BDE when using these databases. http://www.ibobjects.com/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How can I connect to a remote SQL server using Mac OS X? I don't really need a GUI, but it would be nice to have for the color coding and resultset grid. I'd rather not have to use a VM.
Is there a SQL client for Mac OS X that works with MS SQL Server?
Let's work together on a canonical answer.
Native Apps
SQLPro for MSSQL
Navicat
Valentina Studio
TablePlus
Java-Based
Oracle SQL Developer (free)
SQuirrel SQL (free, open source)
Razor SQL
DB Visualizer
DBeaver (free, open source)
SQL Workbench/J (free, open source)
JetBrains DataGrip
Metabase (free, open source)
Netbeans (free, open source, full development environment)
Electron-Based
Visual Studio Code with mssql extension
Azure Data Studio
SQLectron
(TODO: Add others mentioned below)
The Java-based Oracle SQL Developer has a plugin module that supports SQL Server. I use it regularly on my Mac. It's free, too.
Here's how to install the SQL Server plugin:
Run SQL Developer
go to this menu item: Oracle SQL Developer/Preferences/Database/Third-party JDBC Drivers
Click help.
It will have pointers to the JAR files for MySQL, SQL Server, etc.
The SQL Server JAR file is available at http://sourceforge.net/projects/jtds/files/
This will be the second question in a row I've answered with this, so I think it's worth pointing out that I have no affiliation with this product, but I use it and love it and think it's the right answer to this question too: DbVisualizer.
When this question was asked there were very few tools out there were worth much. I also ended up using Fusion and a Windows client. I have tried just about everything for MAC and Linux and never found anything worthwhile. That included dbvisualizer, squirrel (particularly bad, even though the windows haters in my office swear by it), the oracle SQL developer and a bunch of others.
Nothing compared to DBArtizan on Windows as far as I was concerned and I was prepared to use it with Fusion or VirtualBox. I don't use the MS product because it is only limited to MS SQL.
Bottom line is nothing free is worthwhile, nor were most commercial non windows products
However, now (March 2010) I believe there are two serious contenders and worthwhile versions for the MAC and Linux which have a low cost associated with them. The first one is Aqua Data Studio which costs about $450 per user, which is a barely acceptable, but cheap compared to DBArtizan and others with similar functionality (but MS only). The other is RazorSQL which only costs $69 per user.
Aqua data studio is good, but a resource hog and basically pretty sluggish and has non essential features such as the ER diagram tool, which is pretty bad at that. The Razor is lightning fast and is only a 16meg download and has everything an SQL developer needs including a TSQL editor.
So the big winner is RazorSQL and for $69, well worth it and feature ridden. Believe me, after several years of waiting to find a cheap non windows substitute for DBartizan, I have finally found one and I have been very picky.
My employer produces a simple, proof-of-concept HTML5-based SQL client which can be used against any ODBC data source on the web-browser host machine, through the HTML5 WebDB-to-ODBC Bridge we also produce. These components are free, for Mac, Windows, and more.
Applicable to many of the other answers here -- the Type 1 JDBC-to-ODBC Bridge that most are referring to is the one Sun built in to and bundled with the JVM. JVM/JRE/JDK documentation has always advised against using this built-in except in experimental scenarios, or when no other option exists, because this component was built as a proof-of-concept, and was never intended for production use.
My employer makes an enterprise-grade JDBC-to-ODBC Bridge, available as either a Single-Tier (installs entirely on the client application host) or a Multi-Tier (splits components over the client application host and the ODBC data source host, enabling JDBC client applications in any JVM to use ODBC data sources on Mac, Windows, Linux, etc.). This solution isn't free.
All of the above can be used with the ODBC Drivers for Sybase & Microsoft SQL Server (or other databases) we also produce ...
I thought Sequel Pro for MySQL looked pretty interesting. It's hard to find one tool that works with all those databases (especially SQL Server 2005 . . . most people use SQL Server Management Studio and that's Windows only of course).
Squirrel SQL is a Java based SQL client, that I've had good experience with on Windows and Linux. Since it's Java, it should do the trick.
It's open source. You can run multiple sessions with multiple databases concurrently.
I vote for RazorSQL also. It's very powerful in many respects and practically supports most databases out there. I mostly use it for SQL Server, MySQL and PostgreSQL.
DbVisualizer supports many different databases. There is a free edition that I have used previously. Download from here
I have had good success over the last two years or so using Navicat for MySQL.
The UI could use a little updating, but all of the tools and options they provide make the cost justifiable for me.
I use the Navicat clients for MySQL and PostgreSQL and am happy with them. "good" is obviously subjective... how do you judge your DB clients?
I've been using Oracle SQL Developer since the Microsoft software for SQL Server is not currently available on Mac OS X. It works wonders. I would also recommend RazorSQL or SQLGrinder.
I use AquaFold at work on Windows, but it's based on Java and supports Mac OS X.
I like SQLGrinder.
It's built using Cocoa, so it looks a lot better and feels more like an Mac OS X application than all the Java-based application mentioned here.
It uses JDBC drivers to connect to Microsoft SQL Server 2005, FrontBase, MySQL, OpenBase, Oracle, PostgreSQL, and Sybase.
Free trial or $59.
I've used (DB Solo) and I like it a lot. It's only $99 and comparable to many more expensive tools. It supports Oracle, SQL Server, Sybase, MySQL, PostgreSQL and others.
Not sure about open-source, but I've heard good things about http://www.advenio.com/sqlgrinder/ (not tried it, I prefer to write Python scripts to try things out rather than use GUIs;-).
When this question was asked, Microsoft's Remote Desktop for OS X had been unsupported for years. It wasn't a Universal Binary, and I found it to be somewhat buggy (I recall that the application will just quit after a failed connection instead of allowing you to alter the connection info and try again).
At the time I recommended the Open Source CoRD, a good RDP client for Mac.
Since then Microsoft Remote Desktop Client for Mac 2 was released.
I use Eclipse's Database development plugins - like all Java based SQL editors, it works cross platform with any type 4 (ie pure Java) JDBC driver. It's ok for basic stuff (the main failing is it struggles to give transaction control -- auto-commit=true is always set it seems).
Microsoft have a decent JDBC type 4 driver: http://www.microsoft.com/downloads/details.aspx?FamilyId=6D483869-816A-44CB-9787-A866235EFC7C&displaylang=en this can be used with all Java clients / programs on Win/Mac/Lin/etc.
Those people struggling with Java/JDBC on a Mac are presumably trying to use native drivers instead of JDBC ones -- I haven't used (or practically heard of) the ODBC driver bridge in almost 10 years.
It may not be the best solution if you don't already have it, but FileMaker 11 with the Actual SQL Server ODBC driver (http://www.actualtech.com/product_sqlserver.php) worked nicely for a client of mine today. The ODBC driver is only $29, but FileMaker is $299, which is why you might only consider it if you already have it.
This doesn't specifically answer your question, because I'm not sure in any clients exist in Mac OS X, but I generally just Remote Desktop into the server and work through that. Another option is VMware Fusion (which is much better than Parallels in my opinion) + Windows XP + SQL Server Management Studio.
I've used Eclipse with the Quantum-DB plugins for that purpose since I was already using Eclipse anyway.
Ed: phpMyAdmin is for MySQL, but the asker needs something for Microsoft SQL Server.
Most solutions that I found involve using an ODBC Driver and then whatever client application you use. For example, Gorilla SQL claims to be able to do that, even though the project seems abandoned.
Most good solutions are either using Remote Desktop or VMware/Parallels.
Try CoRD and modify what you want directly from the server.
It's open source.
http://cord.sourceforge.net/
For MySQL, there is Querious and Sequel Pro. The former costs US$25, and the latter is free. You can find a comparison of them here, and a list of some other Mac OS X MySQL clients here.
Steve
Since there currently isn't a MS SQL client for Mac OS X, I would, as Modesty has suggested, use Remote Desktop for the Mac.