Re: 4.x series difference

2007-03-20 Thread Edmund Urbani

Propes, Barry L [GCG-NAOT] wrote:

Hello users,
 
A while back I had posted about running different versions on a desktop to see if it caused conflicts, created problems and so on.
 
The versions in question are 4.0.1 and 4.1.3. For a lengthy time, I had used 4.0.1 in my dev. environment and 4.1.3 on our production server, both of these servers in question being Win2K.
 
Several of you replied back and said there should be no problem, and while on version wouldn't do DBCP and the other would allow for it, there seems like little difference.
 
One thing that previously worked in both environments and now seems to not work ok is the structure of a Prepared Statement.
 
I'll create one like I always have, and now Oracle seems to see the semicolon ending the SQL statement as an illegal character, whereas before it did not.
 
I'm not saying or implying this is a Tomcat deal, but I wonder why it would work before and now suddenly would not.
 
Basic prepared statement might look like this:
 
   String prepquer = UPDATE users_dev SET user_name = ?, USER_PASS = ?, USER_TIMSTMP = SYSDATE, USER_DBFLGAG = 0 +

WHERE user_name = ?;;
   PreparedStatement preps = connection.prepareStatement(prepquer);
 
The console now gives me this error, 
java.sql.SQLException: ORA-00911: invalid character.
 
I say now, this behavior actually started coincidentally after I started using 4.1.3 in my dev. environment.
 
If anyone can shed light on this here, feel free. Maybe I should address it in the Oracle forum, which I'll probably go ahead and do.
 
But if it's concretely not Tomcat, let me know that, too.
 
Thanks!




Not sure whether this has anything to do with your problem, but I think it's odd 
that your SQL statement has a trailing semicolon. I never use semicolons with 
JDBC. So I thought maybe that's the invalid character. ... not that this would 
explain why you get this error now and not earlier...


Cheers,
 Edmund

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: 4.x series difference

2007-03-20 Thread Propes, Barry L [GCG-NAOT]
Ok, that might be the problem, but I wonder why now.


-Original Message-
From: Edmund Urbani [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 1:53 PM
To: Tomcat Users List
Subject: Re: 4.x series difference


Propes, Barry L [GCG-NAOT] wrote:
 Hello users,
  
 A while back I had posted about running different versions on a desktop to 
 see if it caused conflicts, created problems and so on.
  
 The versions in question are 4.0.1 and 4.1.3. For a lengthy time, I had used 
 4.0.1 in my dev. environment and 4.1.3 on our production server, both of 
 these servers in question being Win2K.
  
 Several of you replied back and said there should be no problem, and while on 
 version wouldn't do DBCP and the other would allow for it, there seems like 
 little difference.
  
 One thing that previously worked in both environments and now seems to not 
 work ok is the structure of a Prepared Statement.
  
 I'll create one like I always have, and now Oracle seems to see the semicolon 
 ending the SQL statement as an illegal character, whereas before it did not.
  
 I'm not saying or implying this is a Tomcat deal, but I wonder why it would 
 work before and now suddenly would not.
  
 Basic prepared statement might look like this:
  
String prepquer = UPDATE users_dev SET user_name = ?, USER_PASS = ?, 
 USER_TIMSTMP = SYSDATE, USER_DBFLGAG = 0 +
 WHERE user_name = ?;;
PreparedStatement preps = connection.prepareStatement(prepquer);
  
 The console now gives me this error, 
 java.sql.SQLException: ORA-00911: invalid character.
  
 I say now, this behavior actually started coincidentally after I started 
 using 4.1.3 in my dev. environment.
  
 If anyone can shed light on this here, feel free. Maybe I should address it 
 in the Oracle forum, which I'll probably go ahead and do.
  
 But if it's concretely not Tomcat, let me know that, too.
  
 Thanks!
 

Not sure whether this has anything to do with your problem, but I think it's 
odd 
that your SQL statement has a trailing semicolon. I never use semicolons with 
JDBC. So I thought maybe that's the invalid character. ... not that this 
would 
explain why you get this error now and not earlier...

Cheers,
  Edmund

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: 4.x series difference

2007-03-20 Thread Propes, Barry L [GCG-NAOT]
ok, strangely now after removing that semicolon it works as it did/should.

Might have been an old driver I was using before that allowed that I suppose.

-Original Message-
From: Edmund Urbani [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 1:53 PM
To: Tomcat Users List
Subject: Re: 4.x series difference


Propes, Barry L [GCG-NAOT] wrote:
 Hello users,
  
 A while back I had posted about running different versions on a desktop to 
 see if it caused conflicts, created problems and so on.
  
 The versions in question are 4.0.1 and 4.1.3. For a lengthy time, I had used 
 4.0.1 in my dev. environment and 4.1.3 on our production server, both of 
 these servers in question being Win2K.
  
 Several of you replied back and said there should be no problem, and while on 
 version wouldn't do DBCP and the other would allow for it, there seems like 
 little difference.
  
 One thing that previously worked in both environments and now seems to not 
 work ok is the structure of a Prepared Statement.
  
 I'll create one like I always have, and now Oracle seems to see the semicolon 
 ending the SQL statement as an illegal character, whereas before it did not.
  
 I'm not saying or implying this is a Tomcat deal, but I wonder why it would 
 work before and now suddenly would not.
  
 Basic prepared statement might look like this:
  
String prepquer = UPDATE users_dev SET user_name = ?, USER_PASS = ?, 
 USER_TIMSTMP = SYSDATE, USER_DBFLGAG = 0 +
 WHERE user_name = ?;;
PreparedStatement preps = connection.prepareStatement(prepquer);
  
 The console now gives me this error, 
 java.sql.SQLException: ORA-00911: invalid character.
  
 I say now, this behavior actually started coincidentally after I started 
 using 4.1.3 in my dev. environment.
  
 If anyone can shed light on this here, feel free. Maybe I should address it 
 in the Oracle forum, which I'll probably go ahead and do.
  
 But if it's concretely not Tomcat, let me know that, too.
  
 Thanks!
 

Not sure whether this has anything to do with your problem, but I think it's 
odd 
that your SQL statement has a trailing semicolon. I never use semicolons with 
JDBC. So I thought maybe that's the invalid character. ... not that this 
would 
explain why you get this error now and not earlier...

Cheers,
  Edmund

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: 4.x series difference

2007-03-20 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry,

Propes, Barry L [GCG-NAOT] wrote:
 One thing that previously worked in both environments and now seems 
 to not work ok is the structure of a Prepared Statement.
 
 I'll create one like I always have, and now Oracle seems to see the 
 semicolon ending the SQL statement as an illegal character, whereas 
 before it did not.

Have you upgraded your Oracle driver in the process?

I have never put semi-colons in any of my prepared statements, since
it's not actually part of the statement. Usually, the semi-colon is the
statement delimiter for a command-line interface. Since only a single
statement can be executed (right?) through a prepared statement, I would
just remove the semi-colon altogether, since it's not necessary (or even
correct?).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGAEAj9CaO5/Lv0PARAsjsAJ0YEvRWS5yP2ZeXu4WQFAq1edXhBQCeMtJc
6kXOQpEcyg1XTHiymsgkS6s=
=qSr+
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: 4.x series difference

2007-03-20 Thread Propes, Barry L [GCG-NAOT]
yeah, Chris, at one point I did update the Oracle driver, and looking back, I 
believe that was the difference.

In most cases I'm running stored procedures anyway, but occasionally I may be 
running a small prepared statement.

-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 3:12 PM
To: Tomcat Users List
Subject: Re: 4.x series difference


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry,

Propes, Barry L [GCG-NAOT] wrote:
 One thing that previously worked in both environments and now seems 
 to not work ok is the structure of a Prepared Statement.
 
 I'll create one like I always have, and now Oracle seems to see the 
 semicolon ending the SQL statement as an illegal character, whereas 
 before it did not.

Have you upgraded your Oracle driver in the process?

I have never put semi-colons in any of my prepared statements, since
it's not actually part of the statement. Usually, the semi-colon is the
statement delimiter for a command-line interface. Since only a single
statement can be executed (right?) through a prepared statement, I would
just remove the semi-colon altogether, since it's not necessary (or even
correct?).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGAEAj9CaO5/Lv0PARAsjsAJ0YEvRWS5yP2ZeXu4WQFAq1edXhBQCeMtJc
6kXOQpEcyg1XTHiymsgkS6s=
=qSr+
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]