Amen, brother! I wished they'd implement the "IDENTITY" attribute for
DB2/AS400 for auto-increment, thank goodness Turbine fixes that with the
id_table functionality.
Scott
-----Original Message-----
From: Matthew Inger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 19, 2001 4:17 PM
To: [EMAIL PROTECTED]
Subject: RE: OBJECTDATA column in the Turbine base tables...
i've discovered that many things about the DB2/400 driver
do not perform as expected. Though the db2/udb driver has
much more wrong with it. However, most jdbc drivers do not
do a good job of metadata outside of the core stuff, like
table and column lists.
It also doesn't help that while the name DB2/400 implies that
it is a derivative of the DB2 database, it in essence is an
entirely seperate product, developed at separate locations
by different people. As i've heard it termed from someone
on the db2/udb team: the as400 db is a whole different world.
In general, though starting with a DB2/UDB implementation is a
good way to go for the DB2/400. I've only found a few things
that work in db2 that do not on the as400 (ie. "set current schema")
just my $.02
(a sometimes frustrated db2/udb & db2/400 user)
On Wed, 2001-09-19 at 15:54, Weaver, Scott wrote:
> Well, I've fixed my own problem. Here is a run down for anyone else who
> maybe using DB2/400 (IBM's DB2 database for the AS400) with Turbine.
>
> Since the Torque had no implementation for DB2/400, I had to peice it
> together from what had been set up already for regular DB2. Here is where
> the big sticking point was. The db.props for DB2 specifies to use a BLOB
> for VARBINARY like so:
>
> VARBINARY = BLOB (16777215)
>
> So I just figured I would duplicate that for DB2/400 (However, I did have
to
> shorten the length due to system specific considerations)
>
> VARBINARY = BLOB (10728640)
>
> I ran "ant init" and voila! I had a Turbine system running on DB2/400.
> We'll kind of. I was able to log in fine using turbine/turbine but
> everytime I tried to create a new user I would get an "SQL Exception: type
> mismatch." After a little digging, I came upon some one discussing
DB2/400
> and VARBINARY fields in JDBC. From what I gathered, to create a VARBINARY
> in DB2/400, you do not use a BLOB (which I have determined was causing by
> type mismatch error) you use a "VARCHAR FOR BIT DATA" defined like so in
> db.props:
>
> VARBINARY = VARCHAR (32000) FOR BIT DATA
>
> After re-running "ant init" everythings humming along fine.
>
> p.s.
> One more thing. I was having problems with the Village API seeing all my
> columns in my tables as "read-only" which will cause inserts/updates in
> village to fail. This is due to a possible bug in the
> AS400ResultSetMetaData.isReadonly() method which seems to always return
> true. To fix this I altered the source code for
> com.workingdogs.village.Column.populate() like so:
>
> void populate (ResultSetMetaData rsmd, int colNum, String tableName)
> {
> ...
>
>
if(rsmd.getClass().getName().equals("com.ibm.as400.access.AS400JDBCResultSet
> MetaData"))
> {
> this.readOnly = false;
> }
> else
> {
> this.readOnly = rsmd.isReadOnly (columnNumber);
> }
> ...
> }
>
> This is just a temp work-around until I find out why
> AS400ResultSetMetaData.isReadonly() always returns read-only.
>
> Regards,
> Scott
>
>
> -----Original Message-----
> From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 19, 2001 1:28 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: OBJECTDATA column in the Turbine base tables...
>
>
> I removed it (OBJECTDATA) from the turbine-schema.xml and re-built. I
have
> found that it is required because when I tried to sign on to the newapp I
> received an error and the logs alerted me to the fact (via SQL exception)
> that OBJECTDATA could not be found.
>
> The real reason I asked this question in the first place is that every
time
> I create a new user I get an SQL exception saying that their is a type
> mismatch. This only happens when I attempt to create a User and not when
I
> create Roles, Permissions and Groups. I'm using a DB2/400 as the target
> database. I have a sneaky suspicion that this is being caused by
OBJECTDATA
> column and the fact that it is a BLOB. Any help on the cause of this
would
> be greatly appreciated.
>
> Here is a stack trace from the turbine.log:
>
> [Wed Sep 19 11:44:17 EDT 2001] -- ERROR --
> Exception: java.lang.reflect.InvocationTargetException
> Stack Trace follows:
> java.lang.reflect.InvocationTargetException: java.sql.SQLException:
> Statement was INSERT INTO TURBINE_USER ( USER_ID, LOGIN_NAME,
> PASSWORD_VALUE, FIRST_NAME, LAST_NAME, EMAIL, LAST_LOGIN, OBJECTDATA )
> VALUES ( ?, ?, ?, ?, ?, ?, ?, ? ) SQL Error:Data type mismatch.
> at com.workingdogs.village.Record.saveWithInsert(Unknown Source)
> at com.workingdogs.village.Record.save(Unknown Source)
> at com.workingdogs.village.Record.save(Unknown Source)
> at
>
org.apache.turbine.om.peer.BasePeer.insertOrUpdateRecord(BasePeer.java:860)
> at org.apache.turbine.om.peer.BasePeer.doInsert(BasePeer.java:764)
> at org.apache.turbine.om.peer.BasePeer.doInsert(BasePeer.java:657)
> at
>
org.apache.turbine.services.security.db.DBUserManager.createAccount(DBUserMa
> nager.java:399)
> rethrown as org.apache.turbine.util.security.DataBackendException: Failed
to
> create account 'foo': Statement was INSERT INTO TURBINE_USER ( USER_ID,
> LOGIN_NAME, PASSWORD_VALUE, FIRST_NAME, LAST_NAME, EMAIL, LAST_LOGIN,
> OBJECTDATA ) VALUES ( ?, ?, ?, ?, ?, ?, ?, ? ) SQL Error:Data type
mismatch.
> at
>
org.apache.turbine.services.security.db.DBUserManager.createAccount(DBUserMa
> nager.java:404)
> at
>
org.apache.turbine.services.security.BaseSecurityService.addUser(BaseSecurit
> yService.java:392)
> at
>
org.apache.turbine.services.security.TurbineSecurity.addUser(TurbineSecurity
> .java:430)
> at
>
org.apache.turbine.flux.modules.actions.user.FluxUserAction.doInsert(FluxUse
> rAction.java:133)
> at java.lang.reflect.Method.invoke(Native Method)
> ... Miscellanous stack info removed for clarity :)
>
> Thanks,
> Scott
>
>
>
>
> -----Original Message-----
> From: John McNally [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 19, 2001 12:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: OBJECTDATA column in the Turbine base tables...
>
>
> In the user table it is used to store the hashtable of user attributes.
> If you store nothing using User.setPerm(), then you do not need it. I
> do not think the objectdata columns in the other tables are used, but
> could be wrong. There are probably references to the user objectdata
> column due to its being used as I described, but you are free to chop
> away on your local versions of turbine all you want.
>
> john mcnally
>
> "Weaver, Scott" wrote:
> >
> > is it really necessary? Could someone explain what it is used for? Can
I
> > remove it from the turbine-schema.xml and rebuild? If I do that will
> > Turbine still function correctly?
> >
> > Thanks,
> > Scott
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Matt Inger ([EMAIL PROTECTED])
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
as yet, is suspicious." -H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]