Originally posted by Dana Hanna:
I wrote a SQL ODBC toold in Java - it reads from "c:\WINDOWS\system32\ODBC.INI" and parses out the databases. It also launches the ODBC config window by spawning "c:\WINDOWS\system32\odbcad32.exe"
(on win 95-ME and XP), on 2K and NT replace WINDOWS with WINNT.
BTW - check out SquirrelSQL on www.sourceforge.net to see a JDBC driver search and connection saving mechanism...
Originally posted by Gregg Bolinger:
You make a valid argument Rich. I'm glad you got something useful out of this thread. Good luck.
Originally posted by Gregg Bolinger:
It breaks platform independence because Microsoft Windows is the only OS that provides some sort of Datasource Bridge (ODBC). So this task would be specific to Windows. Even though your program would be written specifically for the Windows platform, you should be able to take it to any OS and run it without a hitch. Providing a Windows only solution in the API would break that.
Originally posted by Ernest Friedman-Hill:
As I said, real databases let you get this information from the query language. It's not Java's job to work around a deficiency in Microsoft Access.
Originally posted by Gregg Bolinger:
I used the feel the same way. However, it is outside of the goal of Sun's JAVA to do something like this. As Java is a write once run anywhere HIGH LEVEL language, it wouldn't make since to provide Windows specific functionality to the core Java API.
The OLE DB/ADO/ADO.NET solution has an easy function call to allow the user to do this.
Of course it does. That API was written by Microsoft for Microsoft.
We have no desire to invest a heap of money in a JDBC driver.
Who does? That is why most of them are free.![]()
Originally posted by Paul Wheaton:
Evidence that you come from a MicroSoft world?
Welcome to Java. If you have work to get done, you don't have to drag in the executive and bean counters for permission for every little thing. Damn near everything is free.
Originally posted by Ernest Friedman-Hill:
Well, then you should probably consider building your prototype using that particular alphabet soup rather than Java. Since the whole concept of an "ODBC data source" is platform-dependent, and irrelevant anyplace but Windows, so you might as well just build a Windows-only solution.
Note that by definition, a true relational database offers uniform access to all information through the query language -- including the names of available catalogs (the closest SQL concept to the "data source.") Just because the implementors of the JDBC-ODBC bridge (not written by Sun, incidentally, but by a contractor) didn't go out of their way to work around the inadequacies of the ODBC "technology" is no reason to criticise the Java platform as a whole. If you want to use databases on a computer, Java works just fine. If, on the other hand, you want to use Access on Windows, well, hand Bill your pound of flesh and do it the officially sanctioned way. Don't use a caliper to pound a rusty nail.
Originally posted by Simon Lee:
Rich,
What do you mean by "ODBC/JDBC data sources" ???
Originally posted by Jamie Robertson:
In this day and age, you won't find many people using JDBC-ODBC drivers in production anyways. The deployment and maintenance of thick client programs using JDBC-ODBC bridge on individual PC's is frustrating at best. For all apps ( web and thick clint ), type 4 drivers are more reliable, scalable and are better performers on the whole. Also, type 4 drivers are readily available for almost all databases which begs the question why would someone limit themselves to the JDBC-ODBC bridge anyways?
What you are proposing can be easily implemented via a properties/preferences file anyways.
Jamie
[ December 16, 2003: Message edited by: Jamie Robertson ]
Originally posted by sonny kher:
yeah right, how about i give you a dozen links that say there are hundreds of thousands of unfilled position in IT? ofcourse they will be pre-2001. times change my friend and soon enough they will change again.