john_guthrie

One warning about PreparedStatements - they *may* speed things up, but they may not. Two reasons I can think of:
1) your statement gets "prepared" over on the database, database is heavily used, your prepared statement gets flushed before you get a chance to use it (this would actually slow down preformance, I guess)
2) some drivers (e.g. Sybase jConnect) actually ignore your request to prepare the statement by default (I guess the assumption is that you aren't going to reuse it enough to make it worthwhile to pre-compile the statement). For the jConnect drivers you have to create the Connection with a property set that states you really want to pre-compile. So in this case, if you used the default PreparedStatement, you'd find no difference.
Having said that, I agree that you should use them. Just be aware.

Maybe not the most compelling reason, but we migrated our few PL/SQL SPs to java so that we only have a single language at every tier - java on the app server, java in the database, no need to maintain PL/SQL knowledge (which was pretty iffy to begin with)

It isn't easy. Here's some code we (i.e., a co-worker) wrote to insert a CLOB:
/**
* Helper function to load text into clob.
* Expects row to be locked and connection
* to be opened
*/
private void loadTextIntoClob(Connection conn,int id, String text)
throws SQLException, IOException {
PreparedStatement stmt = conn.prepareStatement("select clobCol from myTable where id = ?");
stmt.setInt(1,id);
ResultSet rs = stmt.executeQuery();
if (rs.next()) {
CLOB clob = (oracle.sql.CLOB)rs.getClob(1);
Writer os = clob.getCharacterOutputStream();
os.write(text);
os.close();
} else {
throw new SQLException("Lost the row before CLOB text could be inserted.");
}
}

I found the O'Reilly "Oracle Essentials" book to be a good starting point. It gets kind of nauseatingly pro-Oracle ("Oracle invented client-server programming"), but it does have the goods.

Note that you state that you have your PATH (not CLASSPATH) set to include classes111.zip - make sure its CLASSPATH. Also, you can look in the ZIP file to make sure the driver that is being complained about is really there.

For the ODBC problem, sounds to me (a unix guy) like you haven't defined the ODBC source to use.
For the other, as someone else has said, it's a classpath problem.
Also, can you connect to Personal Oracle remotely? I thought that was the one restriction that it had, only allowing localhost connectivity.

Short answer: no
The standard SQL insert statement allows for only one table. Having said that, make sure you use a transaction to insert into the three tables (with, alas, three insert statements).

To start, thanks for the helpful replies.
The attribute being set is a String in the Tag class. The static class variable I am trying to use is also a String. It looks to me like the JSP tag, as you say, expects the attribute initializer to be a String, but not only that, it wants a literal, surrounded by quotes. If this is not the case, or if it works differently in other app servers, I'd be interested in knowing.
Again, thanks.

No, that way really confuses the JSP compiler (using weblogic 5.1). It may just be BEA's implementation, but it looks like they are trying to do a String.valueOf() whatever is in quotes, and that thing cannot have JSP code. And without the quotes the tag is not recognized at all (I get an error on the closing tag saying there is no corresponding opening tag).

I have a tag set up now that looks something like this:
<package:mytag value1="howdy">
</package:mytag>
I'd like to be able to use a static string from another class to initialize the value1 attribute, but when I put something like:
<package:mytag value1=AnotherClass.HOWDY_STRING>
</package:mytag>
I get JSP compile errors. Anyone know if this is doable, and, if so, what the syntax is?
Thanks. John

some app servers (weblogic comes to mind) have ways to specify start-up classes that get loaded by the JVM when it initializes. with weblogic 5.1, you add a line like this to your weblogic.properties file:
weblogic.system.startupClass.[virtualName]=[fullPackageName]

servlets write html to your browser. html has nothing to do with swing. html is not java.
if you want to put swing on a web page, you have to use applets. applets have nothing to do with servlets, so you can use any web server to serve applets.

I think the movability of a window is handled by the underlying window manager (e.g. X in unix), so I don't think you can do anything about this. My understanding is that even restricting resize depends on the window manager asking the window whether it can be resized, i.e. if my window manager ignores your window's wishes, I can resize any window I want. Having said that, I think most reasonable window managers will ask .... but not about moving windows, just resizing. Okay, I am rambling now, time to stop...

One thing to note. The "fact" that a PreparedStatement is optimized for reuse may or may not be true on the backend database. In some cases, when you issue a prepareStatement a query plan for that statement is built in the database engine, all ready to run. But query plans take up space and if the database is heavily used your plan may get flushed before you even get a chance to use it.
Also, some JDBC implementations have a default behavior of not even building the query plan (jConnect, Sybase's JDBC driver, is an example of this). They basically ignore the prepareStatement and treat the thing like any other statement (note that with jConnect you *can* force it to actually prepare the statement by setting a property when you build the connection - see Sybase's documentation).
Having said that, I find PreparedStatements easier to work with from a programming aspect. It would be nice though, for debugging, if there were an easy way of getting back as a String the SQL that was actually executed, parameters and all.

In Weblogic 5.1, you can create a webapp and point there. weblogic.properties file has an entry like this:
weblogic.httpd.webApp.myapp=C:/mydir/myjsps
Any reference to http://host:7001/myapp would then go to C:/mydir/myjsps