[jira] Updated: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql

[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Knut Anders Hatlen updated DERBY-1248: -- Attachment: test5.zip Attached 'test5.zip' which contains logs/db from a failure in OnlineBackupTest5.sql. Assert failure in BasePage.shiftUp()

[jira] Updated: (DERBY-1393) PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types

[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen updated DERBY-1393: -- Summary: PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types (was:

[jira] Resolved: (DERBY-1393) PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types

[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen resolved DERBY-1393: --- Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks Bryan! Committed revision 420436.

[jira] Closed: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()

[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen closed DERBY-1364: - Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()

[jira] Closed: (DERBY-1039) Database creation should fail if specified log device path already exists

[ http://issues.apache.org/jira/browse/DERBY-1039?page=all ] Knut Anders Hatlen closed DERBY-1039: - Database creation should fail if specified log device path already exists

[jira] Created: (DERBY-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)

EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String) - Key: DERBY-1493 URL: http://issues.apache.org/jira/browse/DERBY-1493 Project: Derby Type: Bug Components:

[jira] Updated: (DERBY-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)

[ http://issues.apache.org/jira/browse/DERBY-1493?page=all ] Knut Anders Hatlen updated DERBY-1493: -- Description: The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that

[jira] Created: (DERBY-1494) PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client

PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client Key: DERBY-1494 URL: http://issues.apache.org/jira/browse/DERBY-1494 Project:

[jira] Updated: (DERBY-802) OutofMemory Error when reading large blob when statement type is ResultSet.TYPE_SCROLL_INSENSITIVE

[ http://issues.apache.org/jira/browse/DERBY-802?page=all ] Andreas Korneliussen updated DERBY-802: --- Derby Info: [Patch Available] OutofMemory Error when reading large blob when statement type is ResultSet.TYPE_SCROLL_INSENSITIVE

[jira] Commented: (DERBY-1494) PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client

[ http://issues.apache.org/jira/browse/DERBY-1494?page=comments#action_12420005 ] Knut Anders Hatlen commented on DERBY-1494: --- Although both implementations of setNull(int,int) are compliant, I think it would make more sense to change the

[jira] Resolved: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'

[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen resolved DERBY-989: -- Fix Version: 10.2.0.0 Resolution: Fixed Thank you for looking at the patch, Bryan! Committed 'derby-989-javadoc.diff' into trunk with

Regression Test Failure! - Derby 420328 - Sun DBTG

[Auto-generated mail] *Derby* 420328/2006-07-09 19:46:20 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* NA NA NANA SunOS-5.10_i86pc-i386 Details in

[jira] Assigned: (DERBY-1352) sysinfo tests should filter out locale information so that it can be run successfully on locales that are not en_US

[ http://issues.apache.org/jira/browse/DERBY-1352?page=all ] Andreas Korneliussen reassigned DERBY-1352: --- Assign To: Andreas Korneliussen sysinfo tests should filter out locale information so that it can be run successfully on locales that

[jira] Updated: (DERBY-1352) sysinfo tests should filter out locale information so that it can be run successfully on locales that are not en_US

[ http://issues.apache.org/jira/browse/DERBY-1352?page=all ] Andreas Korneliussen updated DERBY-1352: Derby Info: [Patch Available] sysinfo tests should filter out locale information so that it can be run successfully on locales that are not

[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420027 ] Knut Anders Hatlen commented on DERBY-1330: --- I have seen this regression test failure a couple of times lately. Could it be related to this issue? * Diff

[jira] Closed: (DERBY-1477) create JUnit tests for testing BLOB OutOfMemory problems

[ http://issues.apache.org/jira/browse/DERBY-1477?page=all ] Andreas Korneliussen closed DERBY-1477: --- create JUnit tests for testing BLOB OutOfMemory problems Key: DERBY-1477

Re: How to add a new service to Derby?

Okay, for the impatient first, here is how to add a service to derby. We'll code a new service called HelloService for Derby. The steps you need to follow are: Step 1: First, code the interface for your service. This is the interface that Derby will use to locate your service and other modules

[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api

[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12420034 ] Knut Anders Hatlen commented on DERBY-1417: --- derby-1417-2a-rstest-refactor.diff looks good. Committed revision 420497. Add new, lengthless overloads to the

[jira] Updated: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types

[ http://issues.apache.org/jira/browse/DERBY-1476?page=all ] Knut Anders Hatlen updated DERBY-1476: -- Attachment: derby-1476-v1.diff derby-1476-v1.stat derby-1476-v1.diff adds a call to checkForSupportedDataType() in setNull(). It

[jira] Updated: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types

[ http://issues.apache.org/jira/browse/DERBY-1476?page=all ] Knut Anders Hatlen updated DERBY-1476: -- Derby Info: [Patch Available] PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Hello Kathey. Using the org.apache.derby.jdbc.ClientDriver driver to access the Derby database through network, sending a large amount of parameter data with setBinaryStream will cause Network Server to throw an OutOfMemoryException. I'm not sure why you used the words sending a large

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Hello Andreas. I have some question for your comment Reading beggining part, I take your reported phenomena as problem when scrollable resultset is used. However,reading last part, I found your report tells that problem was found also when forward-only resultset was used. I feel some

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Or . Did you use words sending a large amount of as just a meaning of when Network Server receives a large amount of data ? Excuse me for the difficulty of comprehension ... Best regards. TomohitoNakayama wrote: Hello Kathey. Using the org.apache.derby.jdbc.ClientDriver driver to

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

TomohitoNakayama wrote: Hello Andreas. I have some question for your comment Reading beggining part, I take your reported phenomena as problem when scrollable resultset is used. However,reading last part, I found your report tells that problem was found also when forward-only resultset

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Hello Andreas. I see ... H mm. Complex circumstances The program failed in creating error message of OutOfMemoryError ... Please upload your application program. I want to make it possible to see the phenomena by myself. Best regards. Andreas Korneliussen wrote: TomohitoNakayama

[jira] Resolved: (DERBY-1352) sysinfo tests should filter out locale information so that it can be run successfully on locales that are not en_US

[ http://issues.apache.org/jira/browse/DERBY-1352?page=all ] Andreas Korneliussen resolved DERBY-1352: - Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed revision 420522. sysinfo tests

[jira] Assigned: (DERBY-1142) Metadata calls leak memory

[ http://issues.apache.org/jira/browse/DERBY-1142?page=all ] Daniel John Debrunner reassigned DERBY-1142: Assign To: Daniel John Debrunner Metadata calls leak memory -- Key: DERBY-1142 URL:

Re: Language based matching

Kathey Marsden [EMAIL PROTECTED] writes: Does anyone know of an easy built in Java mechanism for Locale sensitive matching? I continue to work with a user trying to develop a strategy for language based string type handling in Derby 10.1. The ordering seems doable with the approach in

[jira] Commented: (DERBY-1142) Metadata calls leak memory

[ http://issues.apache.org/jira/browse/DERBY-1142?page=comments#action_12420085 ] Daniel John Debrunner commented on DERBY-1142: -- An addition to the subset of changes of DERBY-827 fixed the issue, increasing the number of iterations from

[jira] Updated: (DERBY-1274) Network Server does not shutdown the databases it has booted when started and shutdown from the command line

[ http://issues.apache.org/jira/browse/DERBY-1274?page=all ] Fernanda Pizzorno updated DERBY-1274: - Attachment: derby-1274v2.diff The attached patch (derby-1274v2.diff) changes the Network Server so that it will shutdown the databases it has booted

[jira] Updated: (DERBY-1351) lang/forupdate.sql fails with derbyclient in the 10.1 branch

[ http://issues.apache.org/jira/browse/DERBY-1351?page=all ] Andreas Korneliussen updated DERBY-1351: Fix Version: 10.2.0.0 Committed revision 420535 on trunk. Patch still available for 10.1 branch. lang/forupdate.sql fails with derbyclient in

[jira] Updated: (DERBY-1142) Metadata calls leak memory

[ http://issues.apache.org/jira/browse/DERBY-1142?page=all ] Daniel John Debrunner updated DERBY-1142: - Attachment: 1142_close_single_use_activations_draft.txt Draft patch that closes an EmbedResultSet's single use activation when the result

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

TomohitoNakayama wrote: Hello Andreas. I see ... H mm. Complex circumstances The program failed in creating error message of OutOfMemoryError ... Please upload your application program. I want to make it possible to see the phenomena by myself. Best regards. Hi, Yes I will upload the

Regression Test Failure! - TinderBox_Derby 420501 - Sun DBTG

[Auto-generated mail] *TinderBox_Derby* 420501/2006-07-10 13:53:08 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 119.92% SunOS-5.10_i86pc-i386 Details in

[jira] Updated: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

[ http://issues.apache.org/jira/browse/DERBY-550?page=all ] Andreas Korneliussen updated DERBY-550: --- Attachment: BlobOutOfMem.java Attached is a repro. BLOB : java.lang.OutOfMemoryError with network JDBC driver

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Andreas Korneliussen wrote: Kathey Marsden wrote: Tomohito Nakayama (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-550?page=comments#action_12419714 ] Tomohito Nakayama commented on DERBY-550: - I intended to resolve this issue as

Re: DERBY-396: Drop Column dependency questions

Hi Bryan, My $0.02 follows. Cheers-Rick Bryan Pendleton wrote: ... a) RESTRICT processing should consider an index on a column to be a dependent object and fail the DROP COLUMN if the column is used in an index? The ANSI spec doesn't provide much guidance here since ANSI doesn't talk

[jira] Commented: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is

[ http://issues.apache.org/jira/browse/DERBY-1459?page=comments#action_12420111 ] Rick Hillegas commented on DERBY-1459: -- I'm beginning to run a battery of derbyalls against this patch using various VMs with and without jar files. So far derbyall runs

[jira] Updated: (DERBY-551) Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body.

[ http://issues.apache.org/jira/browse/DERBY-551?page=all ] Deepa Remesh updated DERBY-551: --- Attachment: derby-551-draft3.diff derby-551-draft3.status Attaching a new draft patch derby-551-draft3.diff which uses Dan's first suggestion

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Hello. Would it be possible, to create a server side InputStream which requests bytes from the client on demand, and that on the server side we could use ps.setBinaryStream(..) instead of ps.setBytes(..) ? The server would then stream the bytes when doing ps.execute(). Would this work if

Re: Running Tests

Hi Kristian, Sorry for the late reply. I noticed that my code had some problems that wouldn't allow me to run unit tests. Hopefully, all bugs are fixed now. You were correct. JUnit was the problem and now the compile time errors are gone. I think I may be running the test incorrectly. I have

[jira] Updated: (DERBY-551) Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body.

[ http://issues.apache.org/jira/browse/DERBY-551?page=all ] Deepa Remesh updated DERBY-551: --- Derby Info: [Patch Available] Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body.

DERBY-630 not a dup of DERBY-85 - still exists in 10.1.3 - reopen?

Hi, I'm using the new release of Derby, version 10.1.3 (see my sysinfo output below) and I was testing to see if DERBY-85 was fixed, which according to the release notes is included in 10.1.3. DERBY-85 is fixed, but the problem I am running into, which I thought was DERBY-85 is actually the

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

TomohitoNakayama wrote: I think it is needed to find where excessive expanding code exists I agree and think a good step toward that is to make sure there are separate cases filed with reproducible cases for the issues that show different symptoms. I am getting a little

[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420121 ] Mamta A. Satoor commented on DERBY-1330: Knut, the diffs you are noticing is in one of the new tests that I added to grantRevokeDDL.sql The diff is for following

behavior of Statement.getGeneratedKeys()

I would like the community's advice on whether the following Derby behavior is a bug and, if so, whether we would be allowed to change this behavior for 10.2: A) Currently, Derby knows how to automatically generate values for columns of type SMALLINT, INT, and BIGINT. You get this behavior if

[jira] Commented: (DERBY-1486) ERROR 40XD0 - When exracting Blob from a database

[ http://issues.apache.org/jira/browse/DERBY-1486?page=comments#action_12420129 ] Sunitha Kambhampati commented on DERBY-1486: I posted a mail to derby-dev earlier, here is the link.

[jira] Commented: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is

[ http://issues.apache.org/jira/browse/DERBY-1459?page=comments#action_12420134 ] Kathey Marsden commented on DERBY-1459: --- Thanks so much Rick for looking this issue and to Olav for bringing it to the attention of the community. I just wanted to

Re: Running Tests

On 7/10/06, Gokul Soundararajan [EMAIL PROTECTED] wrote: Hi Kristian, Sorry for the late reply. I noticed that my code had some problems that wouldn't allow me to run unit tests. Hopefully, all bugs are fixed now. You were correct. JUnit was the problem and now the compile time errors are

Re: [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

Mamta A. Satoor (JIRA) wrote: Is this a Java behavior that you can count on the order in which items will be added and retrieved from HashMap? At this point, I am not sure, how to make sure that items get added and retrieved in the same order from the HashMap so that we will have

Re: Running Tests

On 7/10/06, Myrna van Lunteren [EMAIL PROTECTED] wrote: Hi Gokul, The test harness spawns off further java processes which may not inherit the classpath if you use -cp. Please see what you get when you add the classes dir, junit.jar and jakarta jar to an environment variable, then run the test.

[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

[ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12420139 ] Stan Bradbury commented on DERBY-571: - Intending to open a documentation sub-task on this - no open issue found regarding docuementing the diagnostic tables of SYSCS_DIAG.

Re: Running Tests

Gokul Soundararajan wrote: Hi Kristian, Sorry for the late reply. I noticed that my code had some problems that wouldn't allow me to run unit tests. Hopefully, all bugs are fixed now. You were correct. JUnit was the problem and now the compile time errors are gone. I think I may be running the

Re: Running Tests

Myrna van Lunteren wrote: On 7/10/06, Myrna van Lunteren [EMAIL PROTECTED] wrote: Hi Gokul, The test harness spawns off further java processes which may not inherit the classpath if you use -cp. Please see what you get when you add the classes dir, junit.jar and jakarta jar to an environment

[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420145 ] Mamta A. Satoor commented on DERBY-1330: Mike responded following on the mailing list quote I do not believe you can count on the order of a HashMap, different JVM's

[jira] Commented: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is

[ http://issues.apache.org/jira/browse/DERBY-1459?page=comments#action_12420146 ] Rick Hillegas commented on DERBY-1459: -- Hi Kathey, Here are some answers to your questions. And don't forget to thank Knut Anders, who suggested this approach! 1) This

Re: behavior of Statement.getGeneratedKeys()

To me this is a problematic issue as i would expect the return type for the keys to match the datatype of the column. Rick Hillegas wrote: I would like the community's advice on whether the following Derby behavior is a bug and, if so, whether we would be allowed to change this behavior for

Re: behavior of Statement.getGeneratedKeys()

Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? 2) If this is a bug, is it permitted to change this behavior in

[jira] Commented: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is

[ http://issues.apache.org/jira/browse/DERBY-1459?page=comments#action_12420154 ] Kathey Marsden commented on DERBY-1459: --- Rick said: And don't forget to thank Knut Anders, who suggested this approach Yes. Thanks Knut Anders! I do not anticipate any

[jira] Updated: (DERBY-1015) Define interface between network server and engine through Java interfaces.

[ http://issues.apache.org/jira/browse/DERBY-1015?page=all ] Sunitha Kambhampati updated DERBY-1015: --- Attachment: Derby1015.p2.diff.txt derby1015.p2.stat.txt I am attaching a phase 2 patch ( derby1015.p2.diff.txt,

Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)

Kathey Marsden wrote: TomohitoNakayama wrote: I think it is needed to find where excessive expanding code exists I agree and think a good step toward that is to make sure there are separate cases filed with reproducible cases for the issues that show different symptoms. I am

Question on trigger recursion

I would appreciate if someone can look at the following comment and share their thoughts: http://issues.apache.org/jira/browse/DERBY-1261#action_12418666 I would like to understand the correct behaviour in the above scenario before adding it as a test case for DERBY-551. Thanks, Deepa

[jira] Commented: (DERBY-1015) Define interface between network server and engine through Java interfaces.

[ http://issues.apache.org/jira/browse/DERBY-1015?page=comments#action_12420160 ] Sunitha Kambhampati commented on DERBY-1015: Please note, there are two pending patches waiting for review. derby1015.diff.txt, derby1015.p2.diff.txt. These two

Re: [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

Mamta A. Satoor (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420145 ] Mamta A. Satoor commented on DERBY-1330: Mike responded following on the mailing list quote I do not believe you can count on the

Re: behavior of Statement.getGeneratedKeys()

Hi Kathey, My gut feeling is that changing this behavior could affect applications like ij which make formatting decisions based on the JDBC types of returned columns. Kathey Marsden wrote: Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1) Is this a

Removing an archived fix version from the fix version list of an issue

I would like to remove the fix version (10.1.2.3) from one of the issues (DERBY-1005) as the full fix for it did not get into 10.1.2.3. But when I try to edit the issue, I see that 10.1.2.3 is showing up as an archived fix version and I do not see an option to remove it. Does anyone know how this

Re: behavior of Statement.getGeneratedKeys()

Rick Hillegas wrote: Hi Kathey, My gut feeling is that changing this behavior could affect applications like ij which make formatting decisions based on the JDBC types of returned columns. I agree, but I am not sure yet how significant that impact might be. I'd like translate it into

Re: behavior of Statement.getGeneratedKeys()

Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, My gut feeling is that changing this behavior could affect applications like ij which make formatting decisions based on the JDBC types of returned columns. If you return the correct column type of the base type, then the formatting

[jira] Created: (DERBY-1495) Attempt to modify an identity column error after resetting identity column

Attempt to modify an identity column error after resetting identity column -- Key: DERBY-1495 URL: http://issues.apache.org/jira/browse/DERBY-1495 Project: Derby Type: Bug Components: SQL

Re: behavior of Statement.getGeneratedKeys()

Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? 2) If this is a

Re: behavior of Statement.getGeneratedKeys()

Lance J. Andersen wrote: Kathey Marsden wrote: Rick Hillegas wrote: Certainly there are these changes for the ResultSet returned by getGeneratedKeys(): o getMetaData() would correspond to the ResultSetMetadata of the base table column and so will have different types, columnwidths

Re: Issue with using dependency manager for table level permission tracking

Hi, I wondered if anyone got a chance to go over my earlier mail and if they think of an alternative way to solve the problem than the one suggested by me. If I don't hear anything in a day or so, then I will go ahead and changeSYSTABLEPERMS to look like SYSCOlPERMS. After that change, I will be

Re: behavior of Statement.getGeneratedKeys()

Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the

JDBC reference implentation

Is Derby, JavaDB or something else the JDBC reference implementation these days?

Re: Issue with using dependency manager for table level permission tracking

Mamta Satoor wrote: [example snipped] revoke select on t1 from user2 -- at this point, only view user2.v1 should get dropped because it depends on the SELECTPRIV on t1. But dependency manager has no way to know that user2.v1 needs only SELECTPRIV and hence only object affected by this

[jira] Created: (DERBY-1496) testSecMec fails with jcc2.8 with 131 jvms

testSecMec fails with jcc2.8 with 131 jvms -- Key: DERBY-1496 URL: http://issues.apache.org/jira/browse/DERBY-1496 Project: Derby Type: Improvement Components: Test Versions: 10.2.0.0 Reporter: Sunitha

Re: behavior of Statement.getGeneratedKeys()

Rick Hillegas wrote: Daniel John Debrunner wrote: Rick Hillegas wrote: This would help customers who want to get the type of a table's generated key from getGeneratedKeys() itself and not have to extract this information from a more complicated series of metadata calls. I'm lost

Re: Issue with using dependency manager for table level permission tracking

That is on my todo list to figure out when I do the revoke privilege implementation. But I am thinking that when a revoke privilege is processed, before dropping the dependent objects, a check will be made to see if some other privilege can replace the privilege being revoked and if so, then make

Re: behavior of Statement.getGeneratedKeys()

These seem reasonable. On the other hand, using getGeneratedKeys() to determine the type name of a table's generated key seems very very unlikely to me. It would require that the application/tool can insert a row of the correct shape, if the app/tool can do that, then it probably

Re: behavior of Statement.getGeneratedKeys()

Daniel John Debrunner wrote: Lance J. Andersen wrote: Kathey Marsden wrote: Rick Hillegas wrote: Certainly there are these changes for the ResultSet returned by getGeneratedKeys(): o getMetaData() would correspond to the

Re: Removing an archived fix version from the fix version list of an issue

On 7/10/06, Deepa Remesh [EMAIL PROTECTED] wrote: I would like to remove the fix version (10.1.2.3) from one of the issues (DERBY-1005) as the full fix for it did not get into 10.1.2.3. But when I try to edit the issue, I see that 10.1.2.3 is showing up as an archived fix version and I do not

Re: Issue with using dependency manager for table level permission tracking

Have you considered using PROVIDERFINDER that is part of dependency system? TableDescriptor, for example, stores column list that a view depends on using ColumnsInTable finder. A similar mechanism might work for TablePermDescriptor. SatheeshOn 7/10/06, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I

Re: Issue with using dependency manager for table level permission tracking

Mamta Satoor wrote: That is on my todo list to figure out when I do the revoke privilege implementation. But I am thinking that when a revoke privilege is processed, before dropping the dependent objects, a check will be made to see if some other privilege can replace the privilege being

[jira] Commented: (DERBY-1486) ERROR 40XD0 - When exracting Blob from a database

[ http://issues.apache.org/jira/browse/DERBY-1486?page=comments#action_12420190 ] David Heath commented on DERBY-1486: I have taken a look at the JDBC 3.0 specification and also the JavaDoc and noticed they did not quite agree on when an auto-commit

Re: Issue with using dependency manager for table level permission tracking

After reading you mail, it seems like with revoke, I can send specific action type to dependent objects ie say REVOKE_SELECT_PRIVILEGE / REVOKE_UPDATE_PRIVILEGE/ REVOKE_REFERENCES_PRIVILEGE etc rather than generic REVOKE_PRIVILEGE and that way dependent objects can see if they depend on that

Regression Test Failure! - TinderBox_Derby 420656 - Sun DBTG

[Auto-generated mail] *TinderBox_Derby* 420656/2006-07-11 01:12:32 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 121.86% SunOS-5.10_i86pc-i386 Details in

Re: behavior of Statement.getGeneratedKeys()

Rick Hillegas wrote: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that we are not compliant and if non-compliance is a bug,

Re: behavior of Statement.getGeneratedKeys()

Kathey Marsden wrote: Rick Hillegas wrote: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that we are not compliant and if