|
|
|
|
|
|
|
|
|
|
|
|
|
dbc:testforwebsphere","sa","sa");Originally posted by Julian Kennedy:
So, is your question how to read a Blob type from a database? If you look at the thread I linked to, that may help you. If you give it a bit of thought you can easily adapt my example to work for you.
Originally posted by Julian Kennedy:
Hi Daniel,
Here is a simple example that I recently posted in this thread.
Do it in a Servlet, not in a JSP.
Hope that helps.
Jules
Originally posted by Peter den Haan:
This was put in there to allow the driver to stream the results at the field level. So when you call rs.getString(2), the driver might just read the second field of the current record from the server's data stream and return that to you - with no way to go back to the first field, or even to return the field a second time.
- Peter
Originally posted by Max Rahder:
Just to continue Ernest Friedman-Hill's observations...
The people at Sun who created the JDBC interface had it easy. They simply described behavior. It's the people at Oracle or DB2 who had to implement the classes! At runtime, when you get your connection, that's where your vendor-specific driver provides that vendor's version of Connection. When you ask the connection to create a statement, you get the vendor's version of Statement. Etc. As always with polymorphism, your code doesn't really care what kinds of objects it has; your code only cares what those objects can do! Since the vendor's objects implement the interfaces, they are type-compatible with your variables, even though their actual class type is some vendor class you've never heard of. For kicks you might get your Connection, Statement, and ResultSet objects and run something like:
System.out.println(aConnection.getClass.getName());
Again... you don't really care *what* the objects are, but this might help solidify the concept that even though your code only contains references to the interface types, at runtime you actually have the vendor's version.
Originally posted by Peter Kristensson:
Hi.
You would use the WSAD to write your J2EE applications.
Then when you're done, you would deploy the application and run it on a "normal" WAS installation. (You cant actully write applications using the WAS, it's only for running them)
WSAD - write applications.
WAS - run applications.
What might confuse you here is that the WSAD is shipped with a couple of "test servers", which is basically a WAS server that runs inside the WSAD (or at least in close proximity to it). These servers are used for testing your applications. But when it comes to setting whole shebang in production, you'd normally want a normal WAS installation without all the WSAD-stuff clinging to it.
hope this helps
/Peter