Previous Thread
Next Thread
Print Thread
Communiqué #2: ODBC #31044 28 Apr 09 11:34 AM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
I'm jumping the gun a little bit here, in that Ty is still (supposedly) reviewing the documentation and procedures for the A-Shell/SQL Version 1.2 update (which supports ODBC), but I thought I would give a heads-up to those who have been waiting for some way to connect to databases other than MySQL. Besides giving you a chance to get started downloading/installing or just thinking about your accessing your database of choice, I'm also looking for some more feedback about preferences.

When we started this, we were mainly thinking about "real" database engines - MySQL (which some purists might not even consider "real"), SQL Server, Oracle, DB2. And, we imagined separate, native connectors for each one, with SQL Server being the next in line after MySQL. But it turns out that Microsoft has deprecated the native TDS interface and advises developers to stick with ODBC or one of its wrappers (such as OLEDB or ADO). So that's what I did, and so we now (or will soon) have an ODBC connector between A-Shell and SQL Server.

However, once you can talk to one ODBC connector, you can (at least theoretically) talk to most or even all of them. Which means that we are potentially opening the door to connecting to everything from DB2 to Excel via this same connector. Is there a problem with that? Actually yes.

The problem is that the ODBC standard, in trying to be all things to all databases, applications, and operating systems, allows for such a wide range of degrees of conformance that really making it work for a particular OS/database combination is almost like developing a new interface. That may be a bit of an exaggeration since the really common stuff, like SELECT * FROM , will probably work similarly across all cases, if we aren't too picky about the precise details of the returned column attributes. But given that the A-Shell developer crowd is willing to shed gallons of bloody ink over issues like millicolumns and the proper use of the Control+Home key, I can easily imagine an extended period of chaotic struggles as we sort out the lines of responsibility between A-Shell, your application, the data source manager, the drivers, and the databases themselves.

Which leads to the question motivating the long-winded intro:

Given the wide range of possibilities presented by ODBC, what do A-Shell developers want or expect to do with it? Is there any consensus about which target database(s) we should focus on first? Is is just A-Shell/Windows developers who care about ODBC, or do Linux/AIX developers also want to use it (perhaps to get at SQL Server from UNIX, or to get at Oracle or DB2)?

While on the subject of ODBC/UNIX, I'm curious if anyone has any experience there. ODBC was essentially invented by Microsoft but not surprisingly they didn't extend it beyond Windows, leaving it to third parties to do so. The main UNIX implementation is unixODBC , which is free, but the connectors generally are not. For example, if you want to connect to SQL Server from UNIX (and a number of people have suggested to me that this is exactly what they want to do), the least expensive connector I've found is from EasySoft at around $1000. There is another one from DataDirect Technologies which appears to start at around $4000. For obvious reasons we're not going to go out and buy one of each just to test them and tweak our interface to work well with them, just on the chance that someone might want to go that route. But we may have to, in order to properly support it, if there really is such a demand. However, if our past experience with the ODBC drivers for ISAM is any indication, the degree of interest withers away pretty quickly when people encounter driver/connector prices upwards of $1000. Which makes me wonder whether the majority of interest in the ODBC connector ends up being for connecting to something very inexpensive, like Access.
Re: Communiqué #2: ODBC #31045 29 Apr 09 02:56 AM
Joined: Sep 2003
Posts: 4,135
Steve - Caliq Offline
Member
Offline
Member
Joined: Sep 2003
Posts: 4,135
Sounding good. smile

It would be nice "at some point" to access/update etc an SQL Server from UNIX as most of our customer are UNIX based, but easier said than done im sure, and possibly costly.

See what other feed back you get. smile

Re: Communiqué #2: ODBC #31046 29 Apr 09 04:11 AM
Joined: Jan 2003
Posts: 128
D
Dominic - Madics Systems Ltd Offline
Member
Offline
Member
D
Joined: Jan 2003
Posts: 128
I would be suprised if MS is actually deprecating TDS. Their own ODBC implementation for SQL Server appears to use it.

Do you have a reference from MS on this?

I guess I am just worried since the SQL Server implementation is the most important to us and we have had problems with ADO etc. even on windows.

Re: Communiqué #2: ODBC #31047 30 Apr 09 10:45 AM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
While I'm looking for that reference, I'm curious how you plan to connect to SQL Server from AIX. Or do you use SQL Server only in pure Windows environments?

Re: Communiqué #2: ODBC #31048 30 Apr 09 11:47 AM
Joined: Sep 2003
Posts: 4,135
Steve - Caliq Offline
Member
Offline
Member
Joined: Sep 2003
Posts: 4,135
"How would we connect to a MS SQL Server from Linux/AIX?"

Good question, im still wondering that myself, and hope someone would come up with a nice answer. smile

Dont think we would use a pure Windows environment as most of our customers are Unix.

Re: Communiqué #2: ODBC #31049 30 Apr 09 11:54 AM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
To provide a little archeological background, TDS (Tabular Data Stream) protocol was invented by SyBase for the original SQL Server and adopted by Microsoft when they licensed the technology which they call Microsoft SQL Server. The main C library was, in both cases, called db-lib. So my original plan was to use the db-lib interface, thinking that was the most "native". But when I looked for the docs at Microsoft, here's what I found:

Programming DB-Library for C where the second paragraph says:

Quote

Warning While the DB-Library API is still supported in Microsoft SQL Server 2000, no future versions of SQL Server will include the files needed to do programming work on applications that use this API. Connections from existing applications written using DB-Library will still be supported in the next version of SQL Server, but this support will also be dropped in a future release. When writing new applications, avoid using DB-Library. When modifying existing applications, you are strongly encouraged to remove dependencies on DB-Library. Instead of DB-Library, you can use Microsoft ActiveX® Data Objects (ADO), OLE DB, or ODBC to access data in SQL Server.
(I think the original reference I found was associated with SQL Server 2005, but the essence was the same.)

That said, you are right that "under the hood", most if not all of the various APIs (ODBC, OLEDB, etc.) communicate with the database server/engine using some form of TDS. But, it seems clear that Microsoft is trying to steer programmers away from using the original native db-lib functions in favor of one of the newer interfaces.

In deciding between ODBC and OLEDB, I preferred ODBC because: a) it doesn't require COM (which is just another layer of complication as far as I'm concerned), and b) it is available under UNIX.

OK, but: isn't ODBC horribly inefficient? That was my understanding, until I stumbled on this:

Using ODBC with SQL Server in which you'll find this quote:
Quote

Performance of ODBC as a Native API

One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API. This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. This translation effort adds extra processing compared with having the application call directly to the native API. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way.

The Microsoft SQL Server ODBC driver is a functional replacement of DB-Library. The SQL Server ODBC driver works with the underlying Net-Libraries in exactly the same manner as the DB-Library DLL. The Microsoft SQL Server ODBC driver has no dependence on the DB-Library DLL, and the driver will function correctly if DB-Library is not even present on the client.

Microsoft's testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.
That's pretty much how I ended up deciding to use ODBC for SQL Server. I may have misunderstood the relationship between ODBC and ADO, and I almost certainly erred in suggesting that OLEDB was a wrapper around ODBC (they both cohabit the Native Client, according to this Native API for SQL Server FAQ ), but none of that really affects the validity of the decision to use ODBC.

That said, there is a "FreeTDS" library for UNIX, and as far as I know, the db-lib for Windows continues to exist, so perhaps there is still room for debate. ODBC is absurdly complex and suffers from all the problems noted above. But it's also quite mainstream, whereas I fear that trying to go around it by directly using a protocol that Microsoft seems determined to keep to themselves is bound to introduce plenty of its own problems.

Re: Communiqué #2: ODBC #31050 30 Apr 09 12:05 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
As for the question of how to connect to SQL Server from AIX/Linux, I may not have given a definitive answer, and certainly haven't tested it, but as discussed in the first entry at the top of this thread, this seems like the place to start:

Quote

The main UNIX implementation is unixODBC , which is free, but the connectors generally are not. For example, if you want to connect to SQL Server from UNIX (and a number of people have suggested to me that this is exactly what they want to do), the least expensive connector I've found is from EasySoft at around $1000.
On that subject, I did manage to get unixODBC installed under Linux and was able to talk to my local MySQL server using the MySQL ODBC connector. (So that suggests that it's not totally vaporware.) I also downloaded the EasySoft driver driver but haven't yet requested an eval license in order to really test it. (Not enough hours in the day.)

Talk about all these extra costs and complexities does raise the question of why use SQL Server at all if most of the clients are on AIX/Linux? (Given how often we get beat up over our prices, it's always surprising to see customers willingly choose more expensive rather than less expensive solutions.)


Moderated by  Jack McGregor, Ty Griffin