This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello Javaranch, . I'm writing back into this one because it's been over two weeks in the IDE board, and I'm not convinced the problem is the environment. . I've been editing a program in JBuilder Foundation 2005 that is written as if it should connect to SQL, but doesn't. I instead get: SQLException: No suitable driver SQLState: 08001 VendorError: 0 . I've also written a microprogram. All it does is connect to the database. And it doesn't throw the above error. . I've also added to the above program to have it edit the database, and that also works. . All the research I've seen on "No suitable driver" has said that either the Class.forName isn't working, or I'm naming the wrong driver. If either were the case, I don't think the microprogram would work, since it uses exactly the same terminology. Also, I have a separate check for the Class.forName, and that error isn't thrown. . The unpleasant possibility is that this is one of those odd behaviours that changes when a comment line is added, rather than being based on the actual code. Or something that shifted in the versions, except then I'm not sure the microprogram should work. I know Java's supposed to be portable and stable, but I can't find the needle in this haystack. . Anyways, here's the offending code block, as best I can tell, in the macroprogram. Italics are comments I'm adding now rather than in the actual program.
So what's a good error-checking heuristic for this kind of problem? What do I look for: Java versions, newer drivers, nicer compilers, or should I just rewrite the macroprogram around the outside of the working microprogram?
I gotta be honest with you I really suspect the environment still.
There are two things that can go wrong usually.
1) The URL is wrong 2) The Class isn't being loaded
If both of those are working then we are left with something bizarre with DriverManager. And I have never seen that one before.
Are you saying that you can have one version that works though in JBuilder? If so then one of the assumptions of 1 or 2 being correct is wrong.
Are there any other environment execution differences between one that works and one that doesn't? Permissions? Something?
Joined: Oct 14, 2005
Wow! Three responses! Mr. Pinchback - I don't think so. Didn't activate it in the first place. What's Hotspot?
mr. derby - That's a mite confusing. Obviously Driver.acceptsURL in the microprogram, so why wouldn't it in the macroprogram? In the macroprogram I've written a loop to run through all the items in the drivermanager (with suggestions from other ranchers) and it returns "com.mysql.jdbc.Driver@650646". Will be seeing if I can figure out how to construct what you're suggesting to ask com.mysql.etc if it acceptsURL.
Mr. Stocker - Both versions are run through JBuilder's debug. All the other fixes work on the macroprogram.jar when I run them outside of JBuilder, it just won't connect... last... step... left... I haven't tried running the microprogram outside. I'm not personally changing any of the settings between one project and the next, and I think it recognizes me as the same user for both settings, but I'll see if I can find any differences. Thanks!
Reid M. Pinchback
Joined: Jan 25, 2002
Originally posted by Zachary Anderson: Wow! Three responses! Mr. Pinchback - I don't think so. Didn't activate it in the first place. What's Hotspot?
I've always found that the hardest bugs to find are the ones that fit a category I hit about once ever two years - just far enough apart that you forget to even think about them. Sometimes nothing is wrong with your code. Sometimes nothing is wrong with your environment, if by environment you mean class path, libraries, database, network.
Sometimes what is wrong is that either your compiler generated the wrong bytecodes, or your JVM has a bug that you only hit for particular sequences of byte codes. Here you are, running around trying to figure out what you did wrong in your code or in configuring your development environment, and the problem isn't in those areas at all.
What I was wondering about is if either (a) you are using the standard Borland compiler, and it has a bug, or (b) the JVM used to run your code in JBuilder has a bug.
Eliminating (a) is a bit tough for you because you are using Foundation, not Developer or Enterprise. In the commercial releases you can select your compiler. You don't really have that option, so I focused on (b) instead.
Once upon a time all Java code was interpreted. Hotspot came later, and you added a command-line option to java.exe to use it. Later was a long time ago; these days Hotspot is the default, interpreted requires an option. "javac.exe -Xint ..." is what you use.
Your code will be *slower*, but at the moment that shouldn't matter. All you want to know is whether or not this is the cause of your problem. If it turns out to be the cause, the solution is typically to find some trivial way of re-organizing your code so it still does what you want, but sidesteps the Hotspot bug.
Yes, wicked esoteric, but I've had it happen and known other developers it has happened to.
Joined: Oct 14, 2005
Settings differences: The only oddity I can see is that both micro- and macro- look into macroprogram's lib folder for the mysql-connector jar, and I think I set that up initially. The code folder is different than the lib folder, though, so I hope it's not complaining about having files in the same area manipulated. I've looked at JBuilder's config file, and it says "addjars ../jdk1.4/lib". Other jars in jdk1.4/lib are showing up on the classpath, but even after I've copied mysql-connector jar into there, it's still not showing up on the JBuilder classpath. (of course, that last one can definitely be attributed to JBuilder oddities... then again, if the copy in macroprogram's folder is good enough for microprogram to work, why doesn't macroprogram work?) Just to flatten every nail, lemme see if I can get that one to add... yes, I can, and macro doesn't seem to care.
acceptsURL: Not sure. I can't figure out how to retrieve or construct the driver appropriately to feed to .acceptsURL.
working on -Xinting...
Maximilian Xavier Stocker
Joined: Sep 20, 2005
When I ran the following code (which is your method above but I added a main so that I can run it by itself) it works. I wanted to check that there was nothing wierd with the URL.
And when I say works. I mean it run and I get the following Exception.
There is nothing wrong with your code. (As has been suspected for some time). There is something awry with your environment. Honestly I strongly suggest you scrap the IDE for now. Make it work in whatever text editor combined with just javac and make it work. Once it does work (which won't take very long at all) you can at that point go back to the IDE and perhaps figure it out.
This is an IDE problem. I am 100% sure of it. And other than that though I have no clue why it is breaking or how to fix it. [ January 21, 2006: Message edited by: Maximilian Stocker ]
This statement from the API documentation for DriverManager may hint at one possible remote possibility (my italics):
"When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application."
I don't use JBuilder but from the description given, it seems possible to me that Zachary has caused it to put the driver jar into the extensions directory. And the extensions directory has its own classloader that is different from the system classloader.
So if JBuilder is like Eclipse, where you put your code into "projects" and define a "build path" for each project, I would try to put the driver jar file into JBuilder's equivalent of the "build path" and not put it into some global classpath that JBuilder provides.