FreeTDS Development Group

[Henry Lafleur <HLafleur AT phoenixforge.com>]

The way that freetds_jdbc is designed, it seems that it JDBC 1.0 was in
mind. The process seems to be:

1) Take the user's (the user being a Java program) query and send it to the
SQL server.
2) Take the response from the SQL server and read it as the user goes
through the result set using next(), if there is a result set. Let the user
go to other result sets, if any.

(My description is a little oversimplified here.)

Given this, how would the setObject be implemented in freetds_jdbc? It seems
that the only way to do this would be for freetds_jdbc to work differently.
One way would be to open a cursor and keep the connection open as the user
moves around the result set with next(), prev(), first(), last(),
movetoinsertrow(), etc. (I didn't verify the method names here) and to
compute update statements using the "where current of <cursor>" SQL
condition. The insert statement is straightforward: use Insert <table name>
... In other words, implement JDBC 2.0.

I know that the 1.0 implementation is the current goal, but has anyone
discussed this?

For your problem Bob, I use an abstraction layer on top of JDBC to handle
table navigation and saving data back to the database. My abstraction layer
requires that tables have keys. Without keys how do you know which record in
the table to change? (a semi-rhetorical question) Since you can't use
cursors, there is no way to know that the record that you are looking at is
the only record that will be changed in an update statement unless you have
a table-wide unique identifier. 

An MS-SQL timestamp field will also work as a key. This also has the
advantage that if the record has changed since you read it, your update will
not change it again since timestamps change on update. You would need to
check to see if no records were affected by the update and tell the user
that someone else changed the record while you were looking at it.

Stored procedures are another solution, which brings us to server-side
programming. They are also much faster that other solutions.

Henry


> -----Original Message-----
> From: Strande, Jon [mailto:JohnS AT nwpasta.com]
> Sent: Tuesday, September 12, 2000 12:53 PM
> To: TDS Development Group
> Subject: [freetds] Re: [JDBC] setObject() - not implemented
> 
> 
> Bob,
> 
> Sorry about that, I meant to write that it 
> does not say that it does not work. Quite a
> difference... My Readme says: "The prepared
> statement class does not have all the data 
> types implemented yet". Again, my apologies.
> 
> So, I am out of luck huh? 
> 
> Thanks Bob,
> 
> Jon
> 
> -----Original Message-----
> From: Bob Kline [mailto:bkline AT rksystems.com]
> Sent: Tuesday, September 12, 2000 1:58 PM
> To: TDS Development Group
> Subject: [freetds] Re: [JDBC] setObject() - not implemented
> 
> 
> On Tue, 12 Sep 2000, Strande, Jon wrote:
> 
> > I have searched for answer for this, so I apologize if this 
> is a repeated
> > question. 
> > 
> > NT 4.0 Sp 5
> > IIS 4
> > Tomcat 
> > JDK 1.3
> > freetds - JDBC V 1.3 1999/03/09 17:15:49
> > 
> > In the readme file it says that setObject works
> > yet I am getting an error "not implemented" when
> > I call:
> > java.lang.Integer myInteger = new... etc.
> > myPreparedStatement.setObject(i, myInteger);
> > 
> 
> The README file that I have doesn't say what yours does.  The 
> one I have
> says that getObject() is implemented for all SQLServer datatypes, but
> says nothing whatsoever about setObject() (which is indeed not
> implemented).  Where did you get your copy of the README file?
> 
> -- 
> Bob Kline
> mailto:bkline AT rksystems.com
> http://www.rksystems.com
> 
> 
> ---
> You are currently subscribed to freetds as: JohnS AT nwpasta.com
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
> 
> ---
> You are currently subscribed to freetds as: 
> HLafleur AT phoenixforge.com
> To unsubscribe, forward this message to 
> $subst('Email.Unsub')
>