Re: [ojb-users] bindSelect() Error in setObject() call...

[Thomas M. <tho...@ho...>]

Hi Corey,

Corey Klaasmeyer wrote:

 > I'm getting the following error when I try to write a new object to the
 > database:
 >
 > [DEFAULT] ERROR: bindSelect failed for:
 > com.klaasmeyer.forefront.om.ec.EcMeterReading{CMK,04172002,1725}, PK: 0,
 > value: CMK
 > Job setObject failed Driver not capable.
 >
 > 	at ojb.broker.accesslayer.JdbcAccess.materializeObject(Unknown
 > Source)
 > 	at ojb.broker.singlevm.PersistenceBrokerImpl.store(Unknown Source)
 > 	at
 > 
com.klaasmeyer.forefront.om.test.TestEquipmentCost.<init>(TestEquipmentCost.
 > java:67)
 > 	at
 > 
com.klaasmeyer.forefront.om.test.TestEquipmentCost.main(TestEquipmentCost.ja
 > va:95)
 > Process terminated with exit code 0
 >
 > Is this a driver issue? Any clues would be appreciated.
 >


Yes this is clearly a driver related issue.
Parameter binding is a common place for problems with all kind of drivers.
in the method ojb.broker.accesslayer.StatementManager.bindUpdate(...)
we solved this by delegating the binding to a Driver specific
Platform. The exact behaviour is thus delegated to a Driver specific class.

For ojb.broker.accesslayer.StatementManager.bindSelect(...), that causes
the problem in your case, this is not yet implemented, but could be
refactored quite easily.

But: I don't have access to your Jdbc driver. SO try to fix this bug on
your own, send in the patch, an we will refactor the Platform interface
to work for bindSelect(...) too.



 > Corey
 >
 > -----Original Message-----
 > From: Corey Klaasmeyer [mailto:Co...@kl...]
 > Sent: Wednesday, April 17, 2002 8:51 AM
 > To: 'Obj...@li...'
 > Subject: [ojb-users] Modifications to Work Around Lame ODBC Drivers...
 >
 >
 > Since I am working with a legacy ODBC driver from Simba, I have had 
to work
 > around exceptions which propogate up from that level. It would be 
great if I
 > could get some feedback on the implications of these changes -- all in
 > accesslayer.
 >
 > 1.) In ConnectionFactoryDefaultImpl, I commented out
 > conn.setAutoCommit(!broker.isInTransaction()).
 >


That's OK. In fact this been moved to the
PlatFormDefaultImpl.initializeJdbcConnection(...) method to allow
different behaviour for certain Platforms.
It's already in CVS !


 > I'm assuming autocommit can remain in its default state of true if
 > transactions are not being used.
 >


ACK


 > 2.) In StatementsForClass I commented out
 > result.setEscapeProcessing(ESCAPEPROCESSING);
 >



With my latest changes it is also possible to set the ESCAPEPROCESSING
   value at runtime from a PlatformImpl. Thus it won't be necessary to
comment out anything....


We just need a PlatformSimbaImpl doing all the special Simba things...

cu,

Thomas


 > It doesn't look like this should have any effect. This is the javadoc for
 > setEscapeProcessing():
 > Sets escape processing on or off. If escape scanning is on (the default),
 > the driver will do escape substitution before sending the SQL 
statement to
 > the database. Note: Since prepared statements have usually been 
parsed prior
 > to making this call, disabling escape processing for PreparedStatements
 > objects will have no effect.
 >
 > Finally, these are obviously not general solutions. I think you will 
need to
 > catch exceptions and react in some rational way. This may be a better 
mail
 > for the developers list...
 >
 > With these changes, OJB is now reading some simple records from our
 > lumbering accounting system.
 >
 > Corey
 >
 >
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 >
 >
 >