2006/1/17, Schroeder, Alexander <[EMAIL PROTECTED]>:
> Could you post the SELECT that you have executed to create the
> result set, and the definition of the table (to get what the key
> columns are)?
Of course.
CREATE TABLE ag_user
(
userid FIXED(9) CONSTRAINT pk_user PRIMARY KEY,
userip VARCHAR(40) NOT NULL,
username VARCHAR(64) NOT NULL,
dnsname VARCHAR(255) NULL
);
CREATE INDEX idx_user
ON ag_user (username, userip);
CREATE INDEX IDX_userip
ON ag_user ( userip );
Java
ResultSet rs = st.executeQuery( "SELECT username, dnsname
FROM ag_user "
+ "WHERE username LIKE '[EMAIL PROTECTED]' AND dnsname =
'-'" );
try {
while ( rs.next() ) {
String mailAddress = rs.getString( 1 );
final int idx = mailAddress.indexOf( '@' );
if ( idx != -1 ) {
// should normally always happen, WHERE clause
ensures '@' is present
String domain = mailAddress.substring( idx + 1 );
rs.updateString( 2, domain );
rs.updateRow();
}
}
}
finally {
JdbcServer.close( rs );
}
> Also, you should tell us what you mean with
> 'strange' results.
That's a bit more difficult. I didn't yet discover a pattern. All I
can say is that with SCROLL_SENSITIVE the total sum of records does
not change but I get additional records that have the "dnsname" field
not updated from "-" to the proper domain part of the mail address.
Example:
before
[EMAIL PROTECTED] -
[EMAIL PROTECTED] -
after
[EMAIL PROTECTED] -
[EMAIL PROTECTED] smbblaw.com
[EMAIL PROTECTED] smbblaw.com
As you might have guessed a number of other records are missing. I
can't say whether they are physically related as I ordered records for
my comparison (copied them to CSV and then did a diff). As far as I
can see at the moment there are records with single and multiple
entries that are duplicated. I'll keep looking and let you know if I
find out anything usefule.
My first rough theory is that with the different scroll sensitiveness
the driver might use different means (e.g. column values vs. row
identifiers) to identify records in the table which in turn may lead
to this behavior. Dunno whether that's a reasonable assumption though.
Thanks for looking into this!
robert
> Regards
> Alexander Schröder
> SAP DB, SAP Labs Berlin
>
> -----Original Message-----
> From: Robert Klemme [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 17. Januar 2006 14:22
> To: maxdb
> Subject: JDBC: Updatable ResultSet - expected behavior?
>
> Hi,
>
> I do an update on a table via a ResultSet. I noticed that this leads
> to strange results if I create the statement like this:
> tx.createStatement( ResultSet.TYPE_SCROLL_SENSITIVE,
> ResultSet.CONCUR_UPDATABLE )
>
> If I do it like this, all is fine:
> tx.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_UPDATABLE )
>
> There is no other user accessing the table. I'm not sure about a
> pattern here but it seems as if the first case has problems if there
> are multiple lines with similar entries.
>
> Is this expected behavior? Is this a bug?
>
> robert
>
>
> Driver Version:
>
> Manifest-Version: 1.0
> Created-By: Apache Ant 1.5
> Main-Class: com.sap.dbtech.jdbc.DriverSapDB
>
> Name: com/sap/dbtech/jdbc/
> Specification-Title: Java Platform API Specification
> Specification-Version: 1.3.0
> Specification-Vendor: Sun Microsystems, Inc.
> Implementation-Title: MaxDB JDBC Driver
> Implementation-Version: 7.6.0 Build 000-000-003-034
> Implementation-Vendor: MySQL MaxDB
>
> Name: com/sap/dbtech/jdbcext/JDBCRowSetSapDB.class
> Java-Bean: True
>
>
> MaxDB Version:
>
> Name CR
> Version 7.5.00.18
> Operating System Windows 2000 (WIN32)
>
> --
> Have a look: http://www.flickr.com/photos/fussel-foto/
>
> --
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe:
> http://lists.mysql.com/[EMAIL PROTECTED]
>
>
>
>
--
Have a look: http://www.flickr.com/photos/fussel-foto/
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
