On 6/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Isn't an implementation of JSR221 writing (clean room) classes in the
java.sql and javax.sql name spaces. (e.g. java.sql.Driver &
javax.sql.DataSource).
Derby is not doing that, Derby is providing an implementation of a JDBC
driver, n
Thanks for your comments, Jean. I would like to add that using
DatabaseMetaData, I am able to find primary keys and foreign keys
using the methods getPrimaryKeys and getImportedKeys, but have not
been able to find a way to find out other details of a table specified
in the original create statemen
Brian McCallister wrote:
>
> On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
>
>> "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
>> final."
>>
>> Where does this restriction come from?
>
>
> Until a spec is final I don't see how you can have a certified complian
Geir Magnusson Jr wrote:
> Daniel John Debrunner wrote:
>
>>Jean T. Anderson wrote:
>>
>>
>>>David posted a good summary of the legal catch-22 at [1]. But the
>>>shortest story is:
>>>
>>> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
>>> + Derby can't ship a GA 10.2 until JDBC
Kathey Marsden wrote:
> Brian McCallister wrote:
>
>> If the interfaces happen to exist in a release before the spec is final,
>> well, cool. Folks using them are at risk of the spec changing at the
>> last
>> minute, so I would put bright red warnings around them if they are event
>> documente
Brian McCallister wrote:
If the interfaces happen to exist in a release before the spec is final,
well, cool. Folks using them are at risk of the spec changing at the
last
minute, so I would put bright red warnings around them if they are event
documented before the official release of the sp
Brian McCallister wrote:
>
> On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
>
>> "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
>> final."
>>
>> Where does this restriction come from?
>
> Until a spec is final I don't see how you can have a certified compliant
>
Daniel John Debrunner wrote:
> Jean T. Anderson wrote:
>
>> David posted a good summary of the legal catch-22 at [1]. But the
>> shortest story is:
>>
>> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
>> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang
Jean T. Anderson wrote:
> David posted a good summary of the legal catch-22 at [1]. But the
> shortest story is:
>
> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
>
> Let's keep this thread confined
On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
"You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final."
Where does this restriction come from?
Until a spec is final I don't see how you can have a certified compliant
implementation of that spec. It might be as
Jean T. Anderson wrote:
> David posted a good summary of the legal catch-22 at [1]. But the
> shortest story is:
>
> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
>
> Let's keep this thread confined
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
Let's keep this thread confined to the JCP issue Andrew raised that to
Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until a
David Van Couvering wrote:
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't ev
That said, it's probably also good to hear from the JCP as well. It
would probably help the ASF gauge what their exposure is and what
approaches they feel comfortable with.
David
David Van Couvering wrote:
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering wrot
Hi, Lance. Sorry I had to challenge you publicly on the list, but
I'm really worried that if we're not very careful we are going to paint
ourselves into a corner and we are going to have to fork Derby in order
to do a Java DB release.
I think we need the JCP lawyers (and it sounds like the AS
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering wrote:
Andrew McIntyre wrote:
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
Even if we did ask Gei
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't even create the bits, then it is
David Van Couvering wrote:
> Andrew McIntyre wrote:
>> Or maybe ask Geir, since he's VP of Java Community Process for the
>> Apache Software Foundation, since similar instances may have come up
>> fairly recently. [3]
>>
>
> Even if we did ask Geir, he's not the last word on it. I'd rather hear
that was MUCH clearer than what rick wrote.. thanks
David Van Couvering wrote:
Ok, this is
very tricky. First, I'd like to make sure we're on the same page here
about Java DB going into the JDK. I think in general the community
thinks it's a good thing for Derby for Java DB to be in the JDK.
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their "abou
Andrew McIntyre wrote:
Anyway, what's the trigger for breaching the contract here? If it's
'creation' alone, then rolling that release candidate surely qualifies
as as creation. If it's 'creation and distribution,' well, is posting
the release candidate in a public forum and on a public website (
[
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417392 ]
Kathey Marsden commented on DERBY-1434:
---
Wish I could delete the comment but the early closed result set with is issue
is not a valid symptom. This wrong line caused th
Jean and Dan, you raise good points
(a) what happens if someone downloads this "GA-ready but not GA" release
of Derby. If for some reason we have to do a respin of the release (see
(b)), how will they later know that it's not actually an official
release of Apache?
(b) is there a possibilit
Andrew McIntyre wrote:
> Call in the lawyers:
>
>> From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
>
> has executed, being a JCP Member (they've even got quotes from Geir
> prominently featured on their "about JCP 2.6 page" [2]):
>
> 5.B. License to Create Independent Impl
On 6/22/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
>> I think we want that database to play well with the approved
>> release candidate which goes GA.
>>
>>
>
>The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>rules) so the databases won't upgrade anyway.
>
>
I apologize fo
Jean T. Anderson wrote:
> David Van Couvering wrote:
> ...
>
>>In order for this to work, we need Java DB to be based on an official,
>>"GA-ready" release of Derby to be what Sun redistributes in Mustang.
>>Otherwise databases created in Mustang will be "locked in" to Java DB.
>>
>>The problem is
David Van Couvering wrote:
...
> In order for this to work, we need Java DB to be based on an official,
> "GA-ready" release of Derby to be what Sun redistributes in Mustang.
> Otherwise databases created in Mustang will be "locked in" to Java DB.
>
> The problem is that it can't *actually* be GA
DataTypeDescriptor.isBinaryType() return false for Types.BLOB
-
Key: DERBY-1443
URL: http://issues.apache.org/jira/browse/DERBY-1443
Project: Derby
Type: Bug
Components: SQL
Versions: 10.1.2.1, 10.1
Ok, this is very tricky. First, I'd like to make sure we're on the same
page here about Java DB going into the JDK. I think in general the
community thinks it's a good thing for Derby for Java DB to be in the
JDK. It gives us great exposure and distribution. I also think the
community would
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ]
Manjula Kutty updated DERBY-1320:
-
Attachment: procedure.java
> Test lang/procedure.java fails with ibm1.5 jvm
> --
>
> Key: DERBY-1320
>
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ]
Manjula Kutty updated DERBY-1320:
-
Attachment: procedure.diff
I thought the same fix for setTransactionIsolation will work for this test too.
But no..When I apply the same change here I'm gett
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ]
Mike Matrigali updated DERBY-959:
-
I missed one file new file in previous commit, here is the svn commit for it:
m1_142:155>svn commit
Adding
java\testing\org\apache\derbyTesting\function
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ]
Mike Matrigali updated DERBY-959:
-
Fix Version: 10.2.0.0
I committed the xxx patch to the trunk:
m1_142:151>svn commit
Sendingjava\drda\org\apache\derby\impl\drda\CodePoint.java
Sending
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>> rules) so the databases won't upgrade anyway.
>>
>>
> I apologize for creating confusion here. We'd like Mustang to ship with
> a fully functional Derby, which creates
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
On 6/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
> Andrew McIntyre wrote:
>> Is this a serious enough issue to warrant another release candidate?
>> Tests that exercise the issue were not contributed along with the fix,
>> and it would be nice to know that this is an issue that is l
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What ha
Rick Hillegas wrote:
> Hi Dan,
>
> Thanks for your comments. Some further remarks follow.
>
> Regards,
> -Rick
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>
>>
>>> Kathey Marsden wrote:
>>>
>>>
>>>
Rick Hillegas wrote:
>>
>>
>>
>>
What happ
Ramin Moazeni wrote:
> Hello,
>
> I am a Google Summer of code participant working on the Derby
> Migration tool project. The High level design document is posted at
> http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument
It's great to see you doing this!
> There are 2 approaches de
Under Deprecated there is:
"A deprecated interface may be removed from the project after four minor
and/or major releases."
http://wiki.apache.org/db-derby/ForwardCompatibility#head-b94fc1d3af5d38a917e2b6c754a8c4213e28f06e
Not sure that really works. With an open source project there could be
fo
[
http://issues.apache.org/jira/browse/DERBY-959?page=comments#action_12417367 ]
Sunitha Kambhampati commented on DERBY-959:
---
Discussion happened on this issue on derby-dev. Here is the link to the
discussion that happened on derby-dev
http://www
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2 branch?
If we fix
Do performance analysis and come up with a good query block size value for the
client to send to the server
---
Key: DERBY-1442
URL: http://issues.apache.org/jira/browse/DERBY
Allow client to be able to send greater than 32k query block size.
---
Key: DERBY-1441
URL: http://issues.apache.org/jira/browse/DERBY-1441
Project: Derby
Type: Improvement
Components: Network Client
Rick Hillegas wrote:
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>> What happens between September 15 and End of October on the 10.2 branch?
>
>> If we fix critical bugs during that time in the 10.2 branch can't they
>> go into the release end of October?
They should be able to. Sin
[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ]
Rick Hillegas updated DERBY-1271:
-
Attachment: derby-1271_copyrights_v02.diff
Attaching derby-1271_copyrights_v02.diff. Same files as previous patch. This
patch removes the "Edition" lines, wh
Rick Hillegas wrote:
> Last week, Sun Microsystems announced that it will bundle Derby with the
> next major release of the reference jdk, Java SE 6, also known as
> Mustang or jdk1.6.
To be precise, Sun Microsystems announced that it will bundle "Java DB"
with Mustang.
http://biz.yahoo.com/prn
Hi Kathey,
Thanks for raising these issues. Here are some clarifications.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the Derby
David Van Couvering wrote:
Hi, Kathey, my silence (and I'm guessing the silence of others) was
general approval of your comments. Did you update the page? I didn't
see any change notifications fly by.
Finally did it.
What kind of clarification are you looking for? I'm afraid I'm
missing
Daniel John Debrunner wrote:
Kristian Waagan wrote:
Hello,
I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API. So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and observati
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the Derby community is bound to?
Here are proposed dates for 10.2 milestones:
August 10 - Feature work committed. 10.2 bra
[
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417352 ]
Kathey Marsden commented on DERBY-1434:
---
Well, I guess I have a little to say about the client code.
It looks like our client SectionManager logic is fatally flawed when
Rick Hillegas (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ]
>
> Rick Hillegas updated DERBY-1271:
> -
>
> Attachment: derby-1271_copyrights.diff
>
> Attaching derby-1271_copyrights.diff. This adjusts dates in the visible
>
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6. If you download the latest Mustang build, you will
see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
parallel to "li
[
http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ]
Kathey Marsden commented on DERBY-1275:
---
I was wondering if anyone had any thoughts on how to implement this
improvement to
provide a way to enable client tracing witho
+1
Regards,
-Rick
Jean T. Anderson wrote:
Jeff Levitt wrote:
As the person who contributed the DITA-converted
documentation, I can tell you I didn't bump the
edition up based on that. I believe the pre-DITA
documentation already said Second Edition.
The pre-DITA (10.0) doc sour
Jeff Levitt wrote:
> As the person who contributed the DITA-converted
> documentation, I can tell you I didn't bump the
> edition up based on that. I believe the pre-DITA
> documentation already said Second Edition.
The pre-DITA (10.0) doc source says First Edition:
https://svn.apache.org/re
> Andrew McIntyre wrote:
>> Is this a serious enough issue to warrant another release candidate?
>> Tests that exercise the issue were not contributed along with the fix,
>> and it would be nice to know that this is an issue that is likely to
>> be hit in known circumstances. If so, a release no
+1
Based on test results:
http://www.multinet.no/~solberg/public/Apache/index.html
Andreas
Andrew McIntyre wrote:
If we have another release candidate, and assuming that the relevant
fixes for it can be committed by Friday, are those testing the release
candidate comfortable with a 72-hour turnaround on the vote for the
new release candidate or will we need another two weeks?
I thin
Mike Matrigali (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]
Mike Matrigali updated DERBY-1156:
--
i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you commit. Still would like to see more testing,
espe
[ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]
Mike Matrigali updated DERBY-1156:
--
i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you
commit. Still would like to see more testing, especially exercising the abort
pa
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ]
Mike Matrigali updated DERBY-1343:
--
Component: (was: Store)
this is an issue with the system catalogs, from discussions on list it looks
like not a store issue.
> It is possible to have
--- Rick Hillegas <[EMAIL PROTECTED]> wrote:
> Daniel John Debrunner wrote:
>
> >Rick Hillegas wrote:
> >
> >
> >
> >>Jean T. Anderson wrote:
> >>
> >>
> >>
> >>>Rick Hillegas wrote:
> >>>
> >>>
> >>>
> >>>
> Thanks, Jean. The Edition line turns up in the
> visible text which
>
[ http://issues.apache.org/jira/browse/DERBY-1429?page=all ]
Mike Matrigali updated DERBY-1429:
--
Component: Services
(was: Store)
This issue should be handled by the monitor, not the store.
> Additional vulnerability to non-determ
Andrew McIntyre wrote:
On 6/20/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
Mike Matrigali wrote:
> I would like to see the fix for DERBY-1392 included in the 10.1.3
> release if there is a second release candidate. While the bug
> is an edge error case, the result is a corrupt db. I beli
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
there is little risk as again the path is not one usually taken.
The change has alre
Kathey Marsden wrote:
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
there is little risk as again the path is not one usually t
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417334 ]
Olav Sandstaa commented on DERBY-1438:
--
Personally, I prefer the text written by the embedded driver ("SQL Exception:")
over the text written by the client driver ("java.
David Van Couvering wrote:
>
>
> Rick Hillegas wrote:
>>
>> I can see that Private Stable applies to the client/server api. These
>> apis should remain forward/backward compatible within a release
>> family. Do Private Stable interfaces turn up in other situations?
>
>
> Yes, that's right. I
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader,
ij running with client driver and jdk 1.6 omits chained exceptions in error
messages
Key: DERBY-1440
URL: http://issues.apache.org/jira/browse/DERBY-1440
Project: Derby
Type: Bug
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417330 ]
David Van Couvering commented on DERBY-1438:
I'll take a look at this and see what I can do. Thanks, Olav.
> Text written by SQLException.toString differs between
[ http://issues.apache.org/jira/browse/DERBY-1438?page=all ]
David Van Couvering reassigned DERBY-1438:
--
Assign To: David Van Couvering
> Text written by SQLException.toString differs between client and embedded
> driver
> -
Rick Hillegas wrote:
> Jean T. Anderson wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>> Thanks, Jean. The Edition line turns up in the visible text which
>>> appears in the printed document. That makes me think that it applies to
>>> something that the customer, the reader, cares about. I don't thin
Investigate removing the antiGC thread in embedded Derby
Key: DERBY-1439
URL: http://issues.apache.org/jira/browse/DERBY-1439
Project: Derby
Type: Improvement
Components: Services
Reporter: Daniel John
Knut Anders Hatlen wrote:
> Daniel John Debrunner <[EMAIL PROTECTED]> writes:
>
>
>>David Van Couvering wrote:
>>
>>>Good news Lance, thanks, I was getting worried if we were going to have
>>>to regularly change column order and break existing applications/IDEs/etc.
>>
>>Hopefully we don't have
Rick Hillegas wrote:
David Van Couvering wrote:
Rick Hillegas wrote:
Hi David,
I had a couple more comments on the compatibility commitments.
Cheers-Rick
- Changes to stored procedures: We will have to change column order if
we add Derby-specific columns to a metadata ResultSet and
Text written by SQLException.toString differs between client and embedded driver
Key: DERBY-1438
URL: http://issues.apache.org/jira/browse/DERBY-1438
Project: Derby
Type: Improvement
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned abou
On 6/22/06, Øystein Grøvlen (JIRA) wrote:
I have sometimes seen the same error message in another context. See
DERBY-637. No triggers involved in my case and not easily reproduced (but I
have seen it several times). I had to shutdown and restart the database to
make the error disappers.
[
http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417323 ]
Deepa Remesh commented on DERBY-1435:
-
Thanks for looking into this Suresh. Now, I can see this from the traces too.
We are re-using the prepared statement after table t1
Rick Hillegas wrote:
> Thanks, Jean. The Edition line turns up in the visible text which
> appears in the printed document. That makes me think that it applies to
> something that the customer, the reader, cares about. I don't think the
> reader is particularly concerned about our transition to dit
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ]
Olav Sandstaa updated DERBY-955:
Derby Info: [Patch Available]
> Get derbyall on jdk1.6
> --
>
> Key: DERBY-955
> URL: http://issues.apache.org/jira/browse/
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ]
Olav Sandstaa updated DERBY-955:
Attachment: bug955_derbyall.diff
This patch contains fixes to the following tests that are failing when
running derbyall with jdk 1.6:
* derbynetclientmats: too
[
http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12417318 ]
Deepa Remesh commented on DERBY-1395:
-
I had seen the first scenario (both connection and statement closed) in
jdbcapi/checkDataSource.java.This is in the checkConnection
[ http://issues.apache.org/jira/browse/DERBY-1313?page=all ]
Fernanda Pizzorno updated DERBY-1313:
-
Attachment: derby-1313v1.pdf
The attached document (derby-1313v1.pdf) contains a short description of the
work done in DERBY-1313 and DERBY-1374, and
Hi David,
You might want to wrap the test in a custom Ant Task. These are
described in the Ant manual: "Developing with Ant"->"Writing Your Own
Task". You can then check the return status of the task and fail the
build if appropriate.
Regards,
-Rick
David Van Couvering wrote:
Hm, a build-t
Kristian Waagan wrote:
> Hello,
>
> I'm working on DERBY-1417; adding new lengthless overloads to the
> streaming API. So far, I have only been looking at implementing this in
> the embedded driver. Based on some comments in the code, I have a few
> questions and observations regarding truncatio
[ http://issues.apache.org/jira/browse/DERBY-1361?page=all ]
Andreas Korneliussen updated DERBY-1361:
Attachment: DERBY-1361v2.diff
DERBY-1361v2.stat
Attaching an updated patch. Two more master files had to be updated because of
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned about our transition to dita. If that
is what Editio
David Van Couvering wrote:
Rick Hillegas wrote:
Hi David,
I had a couple more comments on the compatibility commitments.
Cheers-Rick
- Changes to stored procedures: We will have to change column order if
we add Derby-specific columns to a metadata ResultSet and then a later
JDBC als
Add new LRU Cache Manager
-
Key: DERBY-1437
URL: http://issues.apache.org/jira/browse/DERBY-1437
Project: Derby
Type: Improvement
Components: Services
Reporter: Gokul Soundararajan
Assigned to: Gokul Soundararajan
In databases, ca
Hello,
I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API. So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and observations regarding truncation of trailing blanks in
the variou
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ]
Knut Anders Hatlen reassigned DERBY-1393:
-
Assign To: Knut Anders Hatlen
> PreparedStatement.setObject(Object,int,int) should throw for unsupported types
> -
[
http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417279 ]
Øystein Grøvlen commented on DERBY-1435:
I have sometimes seen the same error message in another context. See
DERBY-637. No triggers involved in my case and not easil
[ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]
Kristian Waagan reassigned DERBY-1417:
--
Assign To: Kristian Waagan
> Add new, lengthless overloads to the streaming api
> --
>
> Ke
[Auto-generated mail]
*Derby* 416051/2006-06-21 19:46:07 CEST
*derbyall*
Failed TestsOK Skip Duration Platform
---
*Jvm: 1.6*
15715700 0 106.56% SunOS-5.10_i86pc-i386
Details in
http://www.multinet.no/~
setEmbeddedCP.ksh and setNetworkCleitn.ksh does not work or gives wrong error
message
-
Key: DERBY-1436
URL: http://issues.apache.org/jira/browse/DERBY-1436
Project: Derby
Type: Bug
1 - 100 of 102 matches
Mail list logo
