You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Armin Waibel <ar...@apache.org> on 2004/08/05 10:24:43 UTC

Re: Please test the new commons-sql dbhandling

Hi Tom,

I made a first test run with maxDB/sapDB and get thousands of errors on 
the console. Is the support for maxDB implemented?

Can you describe me in a few words how dbhandling is working (which 
files are used to generate the sql-query, ...)

regards,
Armin


  CREATE TABLE NESTED_FIELDS_ENTRY
  (
      OBJ_ID INTEGER NOT NULL,
      FK_ID DECIMAL (15,0) NOT NULL,
      NAME VARCHAR (150) UNICODE,
      PRIMARY KEY (OBJ_ID)
  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] 
(at 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
DatabaseException: [-7006] (at 222): Reserved identifier not allowed:INTEGER
     at 
com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71)
....
....
]     OBJ_ID DECIMAL (15,0) NOT NULL,
]     NAME VARCHAR (150) UNICODE,
]     NESTED_VALUE VARCHAR (150) UNICODE,
]     NESTED_DESCRIPTION VARCHAR (150) UNICODE,
]     PRIMARY KEY (OBJ_ID)
] ) failed with com.sap.dbtech.jdbc.exceptions.DatabaseException: 
[-7006] (at 218): Reserved identifier not allowed:DECIMAL
] [ERROR] DDLExecutor - Command -- 
-----------------------------------------------------------------------
] -- NESTED_FIELDS_ENTRY

...

[dbhandling] CREATE TABLE CRT_SUB_PROJECT
[dbhandling] (
[dbhandling]     SUB_ID INTEGER NOT NULL,
[dbhandling]     PROJECT_ID INTEGER,
[dbhandling]     TUTOR_ID INTEGER,
[dbhandling]     NAME VARCHAR (150) UNICODE,
[dbhandling]     PRIMARY KEY (SUB_ID)
[dbhandling] ) failed with 
com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at 214): 
Reserved identifier not allowed:INTEGER
[dbhandling] [ERROR] DDLExecutor - Command -- 
-----------------------------------------------------------------------
[dbhandling] -- OTM_PERSON
[dbhandling] -- 
-----------------------------------------------------------------------


Thomas Dudziak wrote:
> Hi folks,
> 
> just checked in the last changes to the commons-sql dbhandling stuff, 
> and I think it's in a usable state now.
> 
> Since I have only access to few databases, I wanted to ask you whether 
> you could test it against the other databases that OJB supports. More 
> specifically, it would be great if you could test it against these dbs:
> 
> * db2
> * postgresql
> * oracle (8, 9, 10)
> * sybase
> * maxdb
> * microsoft sql server (8, 2000)
> 
> (sapdb/maxdb is currently not supported by commons-sql, but I'll add 
> support in the near future).
> Btw, I had to create an adapted version of the hsqldb profile for the 
> commons-sql dbhandling task because it is executed in the same folder 
> that ant is started in (as opposed to Torque that was run in the 
> target/test folder), so if you want to run the unit tests with 
> commons-sql dbhandling against hsqldb, please use the adapted profile.
> 
> All you'd have to do is to invoke the unit tests like this:
> 
>   ant -Duse-commons-sql=true junit
> 
> and compare the test results with those of a normal unit test run. If 
> some new problem occurs, it would be helpful if you could also provide 
> me with database dumps of the unit test db after for the test runs via 
> either torque and commons-sql, e.q. after executing
> 
>   ant prepare-testdb
> 
> for torque and
> 
>   ant -Duse-commons-sql=true prepare-testdb
> 
> for commons-sql, so I can compare the dbs created by Torque and by 
> commons-sql.
> 
> Thanks,
> Tom
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Thomas Dudziak <to...@first.fhg.de>.
Armin Waibel wrote:

> Thomas Dudziak wrote:
>
>> Armin Waibel wrote:
>>
>>> Here a comparision between the valid torque commands and dbhandling:
>>>
>>> Torque:
>>> -------------------------------------
>>> drop table NESTED_FIELDS_ENTRY cascade ;
>>>
>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>> (
>>>     OBJ_ID INTEGER NOT NULL,
>>>     FK_ID DECIMAL (15,0) NOT NULL,
>>>     NAME VARCHAR (150)
>>> );
>>>
>>> ALTER TABLE NESTED_FIELDS_ENTRY
>>>     ADD PRIMARY KEY (OBJ_ID) ;
>>> -------------------------------------
>>>
>>> dbhandling:
>>> -------------------------------------
>>>  CREATE TABLE NESTED_FIELDS_ENTRY
>>>  (
>>>      OBJ_ID INTEGER NOT NULL,
>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>      NAME VARCHAR (150) UNICODE,
>>>      PRIMARY KEY (OBJ_ID)
>>>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] 
>>> (at
>>> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
>>> DatabaseException: [-7006] (at 222): Reserved identifier not
>>> allowed:INTEGER
>>>     at
>>> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71) 
>>>
>>> ....
>>>
>>> Think the problem is the 'UNICODE' setting in all VARCHAR columns.
>>> If I do
>>>
>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>>  (
>>>      OBJ_ID INTEGER NOT NULL,
>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>      NAME VARCHAR (150),
>>>      PRIMARY KEY (OBJ_ID)
>>>  )
>>>
>>> the table will be created.
>>
>>
>>
>> Interesting. The MaxDB spec says that this way of specifying a 
>> VARCHAR column is valid:
>>
>> http://dev.mysql.com/doc/maxdb/en/d0/763898d21c11d2a97400a0c9449261/content.htm 
>>
>>
>
> oh! I test the following
>
> CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) ASCII,
>      PRIMARY KEY (OBJ_ID)
>  )
>
> This command pass too - really funny. I don't know why.

I know now ;-) It seems you have to create the database specifically as 
a UNICODE db:

http://dev.mysql.com/doc/maxdb/en/13/7e05c2acfead44ade8183219051298/content.htm

So I probably have to change the task to allow specifying 
database-specific properties in the create/alter subtasks, in this case 
whether the MaxDB is UNICODE.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Armin Waibel <ar...@apache.org>.
Thomas Dudziak wrote:
> MaxDB works now with commons-sql dbhandling - I made ASCII (i.e. none 
> specified) the default and added the ability to specify database 
> properties in the task (e.g. for UNICODE).
> However, I get one more unit test failures with commons-sql than I get 
> with torque:
> 
> 

hmm, I think this isn't a real failure. Assume that the failure was 
caused by the internal sapDB connection pool or some other limitation

 > Caused by: com.sap.dbtech.jdbc.exceptions.JDBCDriverException: SAP
 > DBTech JDBC: Cannot connect to jdbc:sapdb://localhost/OJB [Task limit].

I run the dbhandling + test suite on my machine without this failure.

Great work Tom!


Armin



> Testcase: testMultithreadedLazyRead took 9,922 sec
>     Caused an ERROR
> Used ConnectionManager instance could not obtain a connection
> org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager 
> instance could not obtain a connection
>     at 
> org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:660) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAccessImpl.java:550) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1245) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1368) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1347) 
> 
>     at 
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312) 
> 
>     at 
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312) 
> 
>     at 
> org.apache.ojb.broker.MultithreadedReadTest$TestHandleLazyRead.runTestCase(MultithreadedReadTest.java:326) 
> 
>     at 
> org.apache.ojb.junit.JUnitExtensions$MultiThreadedTestCase$TestCaseRunnable.run(JUnitExtensions.java:186) 
> 
>     at java.lang.Thread.run(Thread.java:534)
> Caused by: org.apache.ojb.broker.accesslayer.LookupException: Could not 
> borrow connection from pool - 
> org.apache.ojb.broker.metadata.JdbcConnectionDescriptor: 
> org.apache.ojb.broker.metadata.JdbcConnectionDescriptor@186df0f[
>   jcd-alias=default
>   default-connection=true
>   dbms=MaxDB
>   jdbc-level=2.0
>   driver=com.sap.dbtech.jdbc.DriverSapDB
>   protocol=jdbc
>   sub-protocol=sapdb
>   db-alias=//localhost/OJB
>   user=ojbtest
>   password=*****
>   eager-release=false
>   ConnectionPoolDescriptor={whenExhaustedAction=0, maxIdle=-1, 
> maxActive=21, maxWait=5000, removeAbandoned=false, 
> numTestsPerEvictionRun=10, testWhileIdle=false, 
> minEvictableIdleTimeMillis=600000, testOnReturn=false, 
> logAbandoned=false, removeAbandonedTimeout=300, 
> timeBetweenEvictionRunsMillis=-1, testOnBorrow=true}
>   batchMode=false
>   useAutoCommit=AUTO_COMMIT_SET_TRUE_AND_TEMPORARY_FALSE
>   ignoreAutoCommitExceptions=false
> 
> sequenceDescriptor=org.apache.ojb.broker.metadata.SequenceDescriptor@32784a[ 
> 
>      sequenceManagerClass=class 
> org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl
>      Properties={autoNaming=true, globalSequenceId=false, 
> globalSequenceStart=10000, grabSize=20}
> ]
> ]
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:85) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:116) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:105) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:652) 
> 
>     ... 9 more
> Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error 
> getting Connection from DriverManager with url 
> (jdbc:sapdb://localhost/OJB) and driver (com.sap.dbtech.jdbc.DriverSapDB)
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:259) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(ConnectionFactoryPooledImpl.java:231) 
> 
>     at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:81) 
> 
>     ... 12 more
> Caused by: com.sap.dbtech.jdbc.exceptions.JDBCDriverException: SAP 
> DBTech JDBC: Cannot connect to jdbc:sapdb://localhost/OJB [Task limit].
>     at com.sap.dbtech.jdbc.DriverSapDB.connect(DriverSapDB.java:183)
>     at java.sql.DriverManager.getConnection(DriverManager.java:512)
>     at java.sql.DriverManager.getConnection(DriverManager.java:171)
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:253) 
> 
>     ... 15 more
> 
>     Caused an ERROR
> Used ConnectionManager instance could not obtain a connection
> org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager 
> instance could not obtain a connection
>     at 
> org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:660) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAccessImpl.java:550) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1245) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1368) 
> 
>     at 
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1347) 
> 
>     at 
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312) 
> 
>     at 
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312) 
> 
>     at 
> org.apache.ojb.broker.MultithreadedReadTest$TestHandleLazyRead.runTestCase(MultithreadedReadTest.java:326) 
> 
>     at 
> org.apache.ojb.junit.JUnitExtensions$MultiThreadedTestCase$TestCaseRunnable.run(JUnitExtensions.java:186) 
> 
>     at java.lang.Thread.run(Thread.java:534)
> Caused by: org.apache.ojb.broker.accesslayer.LookupException: Could not 
> borrow connection from pool - 
> org.apache.ojb.broker.metadata.JdbcConnectionDescriptor: 
> org.apache.ojb.broker.metadata.JdbcConnectionDescriptor@186df0f[
>   jcd-alias=default
>   default-connection=true
>   dbms=MaxDB
>   jdbc-level=2.0
>   driver=com.sap.dbtech.jdbc.DriverSapDB
>   protocol=jdbc
>   sub-protocol=sapdb
>   db-alias=//localhost/OJB
>   user=ojbtest
>   password=*****
>   eager-release=false
>   ConnectionPoolDescriptor={whenExhaustedAction=0, maxIdle=-1, 
> maxActive=21, maxWait=5000, removeAbandoned=false, 
> numTestsPerEvictionRun=10, testWhileIdle=false, 
> minEvictableIdleTimeMillis=600000, testOnReturn=false, 
> logAbandoned=false, removeAbandonedTimeout=300, 
> timeBetweenEvictionRunsMillis=-1, testOnBorrow=true}
>   batchMode=false
>   useAutoCommit=AUTO_COMMIT_SET_TRUE_AND_TEMPORARY_FALSE
>   ignoreAutoCommitExceptions=false
> 
> sequenceDescriptor=org.apache.ojb.broker.metadata.SequenceDescriptor@32784a[ 
> 
>      sequenceManagerClass=class 
> org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl
>      Properties={autoNaming=true, globalSequenceId=false, 
> globalSequenceStart=10000, grabSize=20}
> ]
> ]
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:85) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:116) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:105) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:652) 
> 
>     ... 9 more
> Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error 
> getting Connection from DriverManager with url 
> (jdbc:sapdb://localhost/OJB) and driver (com.sap.dbtech.jdbc.DriverSapDB)
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:259) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(ConnectionFactoryPooledImpl.java:231) 
> 
>     at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816) 
> 
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:81) 
> 
>     ... 12 more
> Caused by: com.sap.dbtech.jdbc.exceptions.JDBCDriverException: SAP 
> DBTech JDBC: Cannot connect to jdbc:sapdb://localhost/OJB [Task limit].
>     at com.sap.dbtech.jdbc.DriverSapDB.connect(DriverSapDB.java:183)
>     at java.sql.DriverManager.getConnection(DriverManager.java:512)
>     at java.sql.DriverManager.getConnection(DriverManager.java:171)
>     at 
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:253) 
> 
>     ... 15 more
> 
> 
> 
> Any idea ?
> 
> Tom
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Thomas Dudziak <to...@first.fhg.de>.
Armin Waibel wrote:

> as a sidenote, when I use 'BYTE' it works too. All settings (byte, 
> ascii, none set) except 'UNICODE' working on my computer.
> 
> Make the best of a bad job ;-)
> 
> Armin
> 
> CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) BYTE,
>      PRIMARY KEY (OBJ_ID)
>  )

MaxDB works now with commons-sql dbhandling - I made ASCII (i.e. none 
specified) the default and added the ability to specify database 
properties in the task (e.g. for UNICODE).
However, I get one more unit test failures with commons-sql than I get 
with torque:


Testcase: testMultithreadedLazyRead took 9,922 sec
	Caused an ERROR
Used ConnectionManager instance could not obtain a connection
org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager 
instance could not obtain a connection
	at 
org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:660)
	at 
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAccessImpl.java:550)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1245)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1368)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1347)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312)
	at 
org.apache.ojb.broker.MultithreadedReadTest$TestHandleLazyRead.runTestCase(MultithreadedReadTest.java:326)
	at 
org.apache.ojb.junit.JUnitExtensions$MultiThreadedTestCase$TestCaseRunnable.run(JUnitExtensions.java:186)
	at java.lang.Thread.run(Thread.java:534)
Caused by: org.apache.ojb.broker.accesslayer.LookupException: Could not 
borrow connection from pool - 
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor: 
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor@186df0f[
   jcd-alias=default
   default-connection=true
   dbms=MaxDB
   jdbc-level=2.0
   driver=com.sap.dbtech.jdbc.DriverSapDB
   protocol=jdbc
   sub-protocol=sapdb
   db-alias=//localhost/OJB
   user=ojbtest
   password=*****
   eager-release=false
   ConnectionPoolDescriptor={whenExhaustedAction=0, maxIdle=-1, 
maxActive=21, maxWait=5000, removeAbandoned=false, 
numTestsPerEvictionRun=10, testWhileIdle=false, 
minEvictableIdleTimeMillis=600000, testOnReturn=false, 
logAbandoned=false, removeAbandonedTimeout=300, 
timeBetweenEvictionRunsMillis=-1, testOnBorrow=true}
   batchMode=false
   useAutoCommit=AUTO_COMMIT_SET_TRUE_AND_TEMPORARY_FALSE
   ignoreAutoCommitExceptions=false
 
sequenceDescriptor=org.apache.ojb.broker.metadata.SequenceDescriptor@32784a[
      sequenceManagerClass=class 
org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl
      Properties={autoNaming=true, globalSequenceId=false, 
globalSequenceStart=10000, grabSize=20}
]
]
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:85)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:116)
	at 
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:105)
	at 
org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:652)
	... 9 more
Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error 
getting Connection from DriverManager with url 
(jdbc:sapdb://localhost/OJB) and driver (com.sap.dbtech.jdbc.DriverSapDB)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:259)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(ConnectionFactoryPooledImpl.java:231)
	at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:81)
	... 12 more
Caused by: com.sap.dbtech.jdbc.exceptions.JDBCDriverException: SAP 
DBTech JDBC: Cannot connect to jdbc:sapdb://localhost/OJB [Task limit].
	at com.sap.dbtech.jdbc.DriverSapDB.connect(DriverSapDB.java:183)
	at java.sql.DriverManager.getConnection(DriverManager.java:512)
	at java.sql.DriverManager.getConnection(DriverManager.java:171)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:253)
	... 15 more

	Caused an ERROR
Used ConnectionManager instance could not obtain a connection
org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager 
instance could not obtain a connection
	at 
org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:660)
	at 
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAccessImpl.java:550)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1245)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1368)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1347)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(DelegatingPersistenceBroker.java:312)
	at 
org.apache.ojb.broker.MultithreadedReadTest$TestHandleLazyRead.runTestCase(MultithreadedReadTest.java:326)
	at 
org.apache.ojb.junit.JUnitExtensions$MultiThreadedTestCase$TestCaseRunnable.run(JUnitExtensions.java:186)
	at java.lang.Thread.run(Thread.java:534)
Caused by: org.apache.ojb.broker.accesslayer.LookupException: Could not 
borrow connection from pool - 
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor: 
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor@186df0f[
   jcd-alias=default
   default-connection=true
   dbms=MaxDB
   jdbc-level=2.0
   driver=com.sap.dbtech.jdbc.DriverSapDB
   protocol=jdbc
   sub-protocol=sapdb
   db-alias=//localhost/OJB
   user=ojbtest
   password=*****
   eager-release=false
   ConnectionPoolDescriptor={whenExhaustedAction=0, maxIdle=-1, 
maxActive=21, maxWait=5000, removeAbandoned=false, 
numTestsPerEvictionRun=10, testWhileIdle=false, 
minEvictableIdleTimeMillis=600000, testOnReturn=false, 
logAbandoned=false, removeAbandonedTimeout=300, 
timeBetweenEvictionRunsMillis=-1, testOnBorrow=true}
   batchMode=false
   useAutoCommit=AUTO_COMMIT_SET_TRUE_AND_TEMPORARY_FALSE
   ignoreAutoCommitExceptions=false
 
sequenceDescriptor=org.apache.ojb.broker.metadata.SequenceDescriptor@32784a[
      sequenceManagerClass=class 
org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl
      Properties={autoNaming=true, globalSequenceId=false, 
globalSequenceStart=10000, grabSize=20}
]
]
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:85)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:116)
	at 
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:105)
	at 
org.apache.ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(StatementManager.java:652)
	... 9 more
Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error 
getting Connection from DriverManager with url 
(jdbc:sapdb://localhost/OJB) and driver (com.sap.dbtech.jdbc.DriverSapDB)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:259)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(ConnectionFactoryPooledImpl.java:231)
	at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(ConnectionFactoryPooledImpl.java:81)
	... 12 more
Caused by: com.sap.dbtech.jdbc.exceptions.JDBCDriverException: SAP 
DBTech JDBC: Cannot connect to jdbc:sapdb://localhost/OJB [Task limit].
	at com.sap.dbtech.jdbc.DriverSapDB.connect(DriverSapDB.java:183)
	at java.sql.DriverManager.getConnection(DriverManager.java:512)
	at java.sql.DriverManager.getConnection(DriverManager.java:171)
	at 
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(ConnectionFactoryAbstractImpl.java:253)
	... 15 more



Any idea ?

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Armin Waibel <ar...@apache.org>.
Think this post shed some light on the issue

http://lists.mysql.com/maxdb/10083

Seems maxDB/sapDB doesn't support UNICODE on standard installation by 
default.

Armin

Armin Waibel wrote:

> as a sidenote, when I use 'BYTE' it works too. All settings (byte, 
> ascii, none set) except 'UNICODE' working on my computer.
> 
> Make the best of a bad job ;-)
> 
> Armin
> 
> CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) BYTE,
>      PRIMARY KEY (OBJ_ID)
>  )
> 
> 
> 
> Armin Waibel wrote:
> 
>> Thomas Dudziak wrote:
>>
>>> Armin Waibel wrote:
>>>
>>>> Here a comparision between the valid torque commands and dbhandling:
>>>>
>>>> Torque:
>>>> -------------------------------------
>>>> drop table NESTED_FIELDS_ENTRY cascade ;
>>>>
>>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>>> (
>>>>     OBJ_ID INTEGER NOT NULL,
>>>>     FK_ID DECIMAL (15,0) NOT NULL,
>>>>     NAME VARCHAR (150)
>>>> );
>>>>
>>>> ALTER TABLE NESTED_FIELDS_ENTRY
>>>>     ADD PRIMARY KEY (OBJ_ID) ;
>>>> -------------------------------------
>>>>
>>>> dbhandling:
>>>> -------------------------------------
>>>>  CREATE TABLE NESTED_FIELDS_ENTRY
>>>>  (
>>>>      OBJ_ID INTEGER NOT NULL,
>>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>>      NAME VARCHAR (150) UNICODE,
>>>>      PRIMARY KEY (OBJ_ID)
>>>>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] 
>>>> (at
>>>> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
>>>> DatabaseException: [-7006] (at 222): Reserved identifier not
>>>> allowed:INTEGER
>>>>     at
>>>> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71) 
>>>>
>>>> ....
>>>>
>>>> Think the problem is the 'UNICODE' setting in all VARCHAR columns.
>>>> If I do
>>>>
>>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>>>  (
>>>>      OBJ_ID INTEGER NOT NULL,
>>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>>      NAME VARCHAR (150),
>>>>      PRIMARY KEY (OBJ_ID)
>>>>  )
>>>>
>>>> the table will be created.
>>>
>>>
>>>
>>>
>>> Interesting. The MaxDB spec says that this way of specifying a 
>>> VARCHAR column is valid:
>>>
>>> http://dev.mysql.com/doc/maxdb/en/d0/763898d21c11d2a97400a0c9449261/content.htm 
>>>
>>>
>>
>> oh! I test the following
>>
>> CREATE TABLE NESTED_FIELDS_ENTRY
>>  (
>>      OBJ_ID INTEGER NOT NULL,
>>      FK_ID DECIMAL (15,0) NOT NULL,
>>      NAME VARCHAR (150) ASCII,
>>      PRIMARY KEY (OBJ_ID)
>>  )
>>
>> This command pass too - really funny. I don't know why.
>>
>> regards,
>> Armin
>>
>>
>>> And why it is complaining about the INTEGER column then, is beyond me 
>>> :-)
>>>
>>> Tom
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Armin Waibel <ar...@apache.org>.
as a sidenote, when I use 'BYTE' it works too. All settings (byte, 
ascii, none set) except 'UNICODE' working on my computer.

Make the best of a bad job ;-)

Armin

CREATE TABLE NESTED_FIELDS_ENTRY
  (
      OBJ_ID INTEGER NOT NULL,
      FK_ID DECIMAL (15,0) NOT NULL,
      NAME VARCHAR (150) BYTE,
      PRIMARY KEY (OBJ_ID)
  )



Armin Waibel wrote:

> Thomas Dudziak wrote:
> 
>> Armin Waibel wrote:
>>
>>> Here a comparision between the valid torque commands and dbhandling:
>>>
>>> Torque:
>>> -------------------------------------
>>> drop table NESTED_FIELDS_ENTRY cascade ;
>>>
>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>> (
>>>     OBJ_ID INTEGER NOT NULL,
>>>     FK_ID DECIMAL (15,0) NOT NULL,
>>>     NAME VARCHAR (150)
>>> );
>>>
>>> ALTER TABLE NESTED_FIELDS_ENTRY
>>>     ADD PRIMARY KEY (OBJ_ID) ;
>>> -------------------------------------
>>>
>>> dbhandling:
>>> -------------------------------------
>>>  CREATE TABLE NESTED_FIELDS_ENTRY
>>>  (
>>>      OBJ_ID INTEGER NOT NULL,
>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>      NAME VARCHAR (150) UNICODE,
>>>      PRIMARY KEY (OBJ_ID)
>>>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at
>>> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
>>> DatabaseException: [-7006] (at 222): Reserved identifier not
>>> allowed:INTEGER
>>>     at
>>> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71) 
>>>
>>> ....
>>>
>>> Think the problem is the 'UNICODE' setting in all VARCHAR columns.
>>> If I do
>>>
>>> CREATE TABLE NESTED_FIELDS_ENTRY
>>>  (
>>>      OBJ_ID INTEGER NOT NULL,
>>>      FK_ID DECIMAL (15,0) NOT NULL,
>>>      NAME VARCHAR (150),
>>>      PRIMARY KEY (OBJ_ID)
>>>  )
>>>
>>> the table will be created.
>>
>>
>>
>> Interesting. The MaxDB spec says that this way of specifying a VARCHAR 
>> column is valid:
>>
>> http://dev.mysql.com/doc/maxdb/en/d0/763898d21c11d2a97400a0c9449261/content.htm 
>>
>>
> 
> oh! I test the following
> 
> CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) ASCII,
>      PRIMARY KEY (OBJ_ID)
>  )
> 
> This command pass too - really funny. I don't know why.
> 
> regards,
> Armin
> 
> 
>> And why it is complaining about the INTEGER column then, is beyond me :-)
>>
>> Tom
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Armin Waibel <ar...@apache.org>.
Thomas Dudziak wrote:

> Armin Waibel wrote:
> 
>> Here a comparision between the valid torque commands and dbhandling:
>>
>> Torque:
>> -------------------------------------
>> drop table NESTED_FIELDS_ENTRY cascade ;
>>
>> CREATE TABLE NESTED_FIELDS_ENTRY
>> (
>>     OBJ_ID INTEGER NOT NULL,
>>     FK_ID DECIMAL (15,0) NOT NULL,
>>     NAME VARCHAR (150)
>> );
>>
>> ALTER TABLE NESTED_FIELDS_ENTRY
>>     ADD PRIMARY KEY (OBJ_ID) ;
>> -------------------------------------
>>
>> dbhandling:
>> -------------------------------------
>>  CREATE TABLE NESTED_FIELDS_ENTRY
>>  (
>>      OBJ_ID INTEGER NOT NULL,
>>      FK_ID DECIMAL (15,0) NOT NULL,
>>      NAME VARCHAR (150) UNICODE,
>>      PRIMARY KEY (OBJ_ID)
>>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at
>> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
>> DatabaseException: [-7006] (at 222): Reserved identifier not
>> allowed:INTEGER
>>     at
>> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71) 
>>
>> ....
>>
>> Think the problem is the 'UNICODE' setting in all VARCHAR columns.
>> If I do
>>
>> CREATE TABLE NESTED_FIELDS_ENTRY
>>  (
>>      OBJ_ID INTEGER NOT NULL,
>>      FK_ID DECIMAL (15,0) NOT NULL,
>>      NAME VARCHAR (150),
>>      PRIMARY KEY (OBJ_ID)
>>  )
>>
>> the table will be created.
> 
> 
> Interesting. The MaxDB spec says that this way of specifying a VARCHAR 
> column is valid:
> 
> http://dev.mysql.com/doc/maxdb/en/d0/763898d21c11d2a97400a0c9449261/content.htm 
> 
>

oh! I test the following

CREATE TABLE NESTED_FIELDS_ENTRY
  (
      OBJ_ID INTEGER NOT NULL,
      FK_ID DECIMAL (15,0) NOT NULL,
      NAME VARCHAR (150) ASCII,
      PRIMARY KEY (OBJ_ID)
  )

This command pass too - really funny. I don't know why.

regards,
Armin


> And why it is complaining about the INTEGER column then, is beyond me :-)
> 
> Tom
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Thomas Dudziak <to...@first.fhg.de>.
Armin Waibel wrote:

> Here a comparision between the valid torque commands and dbhandling:
>
> Torque:
> -------------------------------------
> drop table NESTED_FIELDS_ENTRY cascade ;
>
> CREATE TABLE NESTED_FIELDS_ENTRY
> (
>     OBJ_ID INTEGER NOT NULL,
>     FK_ID DECIMAL (15,0) NOT NULL,
>     NAME VARCHAR (150)
> );
>
> ALTER TABLE NESTED_FIELDS_ENTRY
>     ADD PRIMARY KEY (OBJ_ID) ;
> -------------------------------------
>
> dbhandling:
> -------------------------------------
>  CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) UNICODE,
>      PRIMARY KEY (OBJ_ID)
>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at
> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
> DatabaseException: [-7006] (at 222): Reserved identifier not
> allowed:INTEGER
>     at
> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71) 
>
> ....
>
> Think the problem is the 'UNICODE' setting in all VARCHAR columns.
> If I do
>
> CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150),
>      PRIMARY KEY (OBJ_ID)
>  )
>
> the table will be created.

Interesting. The MaxDB spec says that this way of specifying a VARCHAR 
column is valid:

http://dev.mysql.com/doc/maxdb/en/d0/763898d21c11d2a97400a0c9449261/content.htm

And why it is complaining about the INTEGER column then, is beyond me :-)

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Please test the new commons-sql dbhandling

Posted by Armin Waibel <ar...@apache.org>.
Here a comparision between the valid torque commands and dbhandling:

Torque:
-------------------------------------
drop table NESTED_FIELDS_ENTRY cascade ;

CREATE TABLE NESTED_FIELDS_ENTRY
(
     OBJ_ID INTEGER NOT NULL,
     FK_ID DECIMAL (15,0) NOT NULL,
     NAME VARCHAR (150)
);

ALTER TABLE NESTED_FIELDS_ENTRY
     ADD PRIMARY KEY (OBJ_ID) ;
-------------------------------------

dbhandling:
-------------------------------------
  CREATE TABLE NESTED_FIELDS_ENTRY
  (
      OBJ_ID INTEGER NOT NULL,
      FK_ID DECIMAL (15,0) NOT NULL,
      NAME VARCHAR (150) UNICODE,
      PRIMARY KEY (OBJ_ID)
  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at
222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
DatabaseException: [-7006] (at 222): Reserved identifier not
allowed:INTEGER
     at
com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71)
....

Think the problem is the 'UNICODE' setting in all VARCHAR columns.
If I do

CREATE TABLE NESTED_FIELDS_ENTRY
  (
      OBJ_ID INTEGER NOT NULL,
      FK_ID DECIMAL (15,0) NOT NULL,
      NAME VARCHAR (150),
      PRIMARY KEY (OBJ_ID)
  )

the table will be created.

regards,
Armin


Armin Waibel wrote:

> Hi Tom,
> 
> I made a first test run with maxDB/sapDB and get thousands of errors on 
> the console. Is the support for maxDB implemented?
> 
> Can you describe me in a few words how dbhandling is working (which 
> files are used to generate the sql-query, ...)
> 
> regards,
> Armin
> 
> 
>  CREATE TABLE NESTED_FIELDS_ENTRY
>  (
>      OBJ_ID INTEGER NOT NULL,
>      FK_ID DECIMAL (15,0) NOT NULL,
>      NAME VARCHAR (150) UNICODE,
>      PRIMARY KEY (OBJ_ID)
>  ) failed <com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at 
> 222): Reserved identifier not allowed:INTEGER>com.sap.dbtech.jdbc
> DatabaseException: [-7006] (at 222): Reserved identifier not 
> allowed:INTEGER
>     at 
> com.sap.dbtech.jdbc.packet.ReplyPacket.createException(ReplyPacket.java:71)
> ....
> ....
> ]     OBJ_ID DECIMAL (15,0) NOT NULL,
> ]     NAME VARCHAR (150) UNICODE,
> ]     NESTED_VALUE VARCHAR (150) UNICODE,
> ]     NESTED_DESCRIPTION VARCHAR (150) UNICODE,
> ]     PRIMARY KEY (OBJ_ID)
> ] ) failed with com.sap.dbtech.jdbc.exceptions.DatabaseException: 
> [-7006] (at 218): Reserved identifier not allowed:DECIMAL
> ] [ERROR] DDLExecutor - Command -- 
> -----------------------------------------------------------------------
> ] -- NESTED_FIELDS_ENTRY
> 
> ...
> 
> [dbhandling] CREATE TABLE CRT_SUB_PROJECT
> [dbhandling] (
> [dbhandling]     SUB_ID INTEGER NOT NULL,
> [dbhandling]     PROJECT_ID INTEGER,
> [dbhandling]     TUTOR_ID INTEGER,
> [dbhandling]     NAME VARCHAR (150) UNICODE,
> [dbhandling]     PRIMARY KEY (SUB_ID)
> [dbhandling] ) failed with 
> com.sap.dbtech.jdbc.exceptions.DatabaseException: [-7006] (at 214): 
> Reserved identifier not allowed:INTEGER
> [dbhandling] [ERROR] DDLExecutor - Command -- 
> -----------------------------------------------------------------------
> [dbhandling] -- OTM_PERSON
> [dbhandling] -- 
> -----------------------------------------------------------------------
> 
> 
> Thomas Dudziak wrote:
> 
>> Hi folks,
>>
>> just checked in the last changes to the commons-sql dbhandling stuff, 
>> and I think it's in a usable state now.
>>
>> Since I have only access to few databases, I wanted to ask you whether 
>> you could test it against the other databases that OJB supports. More 
>> specifically, it would be great if you could test it against these dbs:
>>
>> * db2
>> * postgresql
>> * oracle (8, 9, 10)
>> * sybase
>> * maxdb
>> * microsoft sql server (8, 2000)
>>
>> (sapdb/maxdb is currently not supported by commons-sql, but I'll add 
>> support in the near future).
>> Btw, I had to create an adapted version of the hsqldb profile for the 
>> commons-sql dbhandling task because it is executed in the same folder 
>> that ant is started in (as opposed to Torque that was run in the 
>> target/test folder), so if you want to run the unit tests with 
>> commons-sql dbhandling against hsqldb, please use the adapted profile.
>>
>> All you'd have to do is to invoke the unit tests like this:
>>
>>   ant -Duse-commons-sql=true junit
>>
>> and compare the test results with those of a normal unit test run. If 
>> some new problem occurs, it would be helpful if you could also provide 
>> me with database dumps of the unit test db after for the test runs via 
>> either torque and commons-sql, e.q. after executing
>>
>>   ant prepare-testdb
>>
>> for torque and
>>
>>   ant -Duse-commons-sql=true prepare-testdb
>>
>> for commons-sql, so I can compare the dbs created by Torque and by 
>> commons-sql.
>>
>> Thanks,
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org