[jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_12313564 ] David Van Couvering commented on DERBY-296: --- I forgot to add, I did do some spot-checks of your final document, and it looks good. I can't guarantee I didn't miss anything, though. Document error messages in the Derby Reference Manual - Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Versions: 10.1.0.0 Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Fix For: 10.1.0.0 Attachments: ErrorMessageGenerator.java, derby296withchanges.zip, rrefexcept13113.dita I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
--- Myrna van Lunteren [EMAIL PROTECTED] wrote:
On 6/10/05, David Van Couvering (JIRA)
derby-dev@db.apache.org wrote:
[
http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_12313354
]
David Van Couvering commented on DERBY-296:
---
Well, I'm looking at the patch, and while I'm I
spend time verifying they
are all correct, I want to ask a couple of meta
questions:
[..snip..]
- I know there is an ErrorMessage VTI that prints
out all the error
messages and SQLSTATEs. Would it make more sense
just to document to a user
how they could use ij to print out these messages
from the VTI? This way you
wouldn't have to continue to maintain this list
and try and make sure it's
consistent with reality, which seems like a task
meant more for Sisyphus
than anyone else :)
[..snip..]
My 2c...: It's in the engine javadoc...But I admit
it was harder to find
than I thought. In old Cloudscape manuals this was
documented...I couldn't
find an obvious spot in the current manuals...(sorry
if I was particularly
blind it's there).
I am wondering whether users are so used to browsing
error message manuals
for other databases that they have a hard time using
the ErrorMessage VTI?
Plus, you'd need ij...(or issue a separate sql
command at least).
Maybe we can add more value to this document over
the VTI by adding
debugging tips and hints where it seems appropriate
at some point...?
Myrna
Yes, my thoughts were similar to Myrna's. At a later
date, it might be nice to include more information
here for many of the problem messages. A more
detailed explanation as well as a suggested user
response to the error are good ways to help the user
in ways they wouldn't get if they just had the error
message itself. For this release, my idea was to just
get the messages doc'd, so we'd have a baseline for
future releases. For now, the only thing these doc'd
message offer that the actual message strings lack is
a value name for the parameters. This can help users
who may not have named databases, tables, views, etc
very clearly, or don't understand what the values are
that the message is returning. So instead of seeing a
{0} in the message text, the doc replaces it with
tableName for example. As we work on documenting
these messages better, we can replace some of the more
generic values with more descriptive substitutions.
The above two reasons provide better information to
the user than just telling them to output it from the
VTI, but also make it hard to run some sort of script
to create DITA from the VTI output. While I think
that would be very helpful indeed (and much faster),
we would still have to go back each time and add the
message details and user responses, as well as the
substituted parameter values.
However, if there is indeed a way to print out the
messages from the VTI, I think if a user just wants to
do that instead of looking at the docs, and the
command is available to them, then there should be
instructions on how to do that in the docs. If
someone wants to open a JIRA issue to do that, I'd be
happy to take on that task. I'd appreciate it if you
could provide the command to do it, as well as a
suggestion of which book and which part of that book
to place it, as that will make creating the pacth much
easier, and more likely to make it in 10.1.
Re: [jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
I am not sure if we should document this syntax. This is highly unusual syntax and definitely not standard. An interesting enhancement to Derby would be to convert these diagnostic VTIs into pseudo system tables. Derby has SYSCS_UTIL and other system schemas and it would be great to provide a pseudo system table interface to all diagnostic VTIs as system tables in one of these system schemas. Would be a great project to learn and enhance Derby SQL compilation and schema management areas. If there is any interest, I could file a Jira ENHANCEMENT request and provide some information Satheesh The way to get it to work currently I found in the tests (org.apache.derbyTesting.functionTests.tests.lang.errorCode.java) you do: (in ij:) select * from new org.apache.derby.diag.ErrorMessages() c and that dumps out all messages. To get just one particular message, you'd do: select * from new org.apache.derby.diag.ErrorMessages() c where sql_state='07000'; I am wondering though, is it ok to document this? It's very non-standard way of doing things... At the same time, to recreate your doc with additional comments,it must be possible to writea program that uses the ErrorMessages vti in combination with an extra file(/extra files) attaches the extra hints for each errormessage...And build the error message doc up that way. So you'd miss a manual step to keep error messages and debugging hints in sync.
Re: [jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
On 6/10/05, David Van Couvering (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_12313354 ]David Van Couvering commented on DERBY-296:---Well, I'm looking at the patch, and while I'm I spend time verifying they are all correct, I want to ask a couple of meta questions: [..snip..]- I know there is an ErrorMessage VTI that prints out all the error messages and SQLSTATEs.Would it make more sense just to document to a user how they could use ij to print out these messages from the VTI?This way you wouldn't have to continue to maintain this list and try and make sure it's consistent with reality, which seems like a task meant more for Sisyphus than anyone else :) [..snip..] My 2c...: It's in the engine javadoc...But I admit it was harder to find than I thought. In old Cloudscape manuals this was documented...I couldn't find an obvious spot in the current manuals...(sorry if I was particularly blind it's there). I amwondering whetherusers are soused to browsing error message manuals for other databases that they have a hard time using the ErrorMessage VTI? Plus, you'd need ij...(or issue a separate sql command at least). Maybewe canadd more value to this document over the VTIbyadding debugging tips and hints where it seems appropriateat some point...?Myrna
[jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_12313324 ] Jeff Levitt commented on DERBY-296: --- Could someone review my patch to verify that all the correct changes are in? If everything looks good, then I'd like to have this committed so that the messages are available in the documentation for 10.1. Thanks! Document error messages in the Derby Reference Manual - Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Versions: 10.1.0.0 Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Fix For: 10.1.0.0 Attachments: derby296withchanges.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-296) Document error messages in the Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_12313354 ] David Van Couvering commented on DERBY-296: --- Well, I'm looking at the patch, and while I'm I spend time verifying they are all correct, I want to ask a couple of meta questions: - Can you give me a sense of how a user would use this? All the error messages I have seen in the log print out the SQLSTATE and the error message. Are there situations when all you get is the SQLSTATE? Or is this for developers so they can write code to perform certain actions when they get a specific SQLSTATE? - I know there is an ErrorMessage VTI that prints out all the error messages and SQLSTATEs. Would it make more sense just to document to a user how they could use ij to print out these messages from the VTI? This way you wouldn't have to continue to maintain this list and try and make sure it's consistent with reality, which seems like a task meant more for Sisyphus than anyone else :) - Alternately, could you write a script that runs the VTI and generates the DITA for you? I could probably write one pretty quick if you'd like... Document error messages in the Derby Reference Manual - Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Versions: 10.1.0.0 Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Fix For: 10.1.0.0 Attachments: derby296withchanges.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-296) Document
I'll make it a subtask, and make sure derbyall passes when I'm done. I'm not sure what you mean by gotchas in the locale files, any tips would be appreciated; otherwise I'm going to focus on cleaning up the text and fixing any necessary diffs in test output. Cheers, David Jean T. Anderson wrote: David Van Couvering wrote: I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. Users would definitely appreciate your contribution! It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Unfortunately Jeff is on vacation, will be back June 6 if I remember right. So all I know is what he posted to Jira. Would I submit this as an independent patch to the same JIRA item? Note Or maybe open a sub task and submit a patch to that? My guess is there are additional things to watch out for; for example, updating the tests to reflect the changed messages so derbyall passes. Also, I don't know what gotchas might be out in the locale files -- would be another thing to follow up on. Anything else, derby developers? also that I may find bugs in the messages that would require a redo of the documentation... In my opinion, the docs (including any doc patches submitted) should be changed to match the code. -jean
Re: [jira] Commented: (DERBY-296) Document
David Van Couvering wrote: I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. Users would definitely appreciate your contribution! It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Unfortunately Jeff is on vacation, will be back June 6 if I remember right. So all I know is what he posted to Jira. Would I submit this as an independent patch to the same JIRA item? Note Or maybe open a sub task and submit a patch to that? My guess is there are additional things to watch out for; for example, updating the tests to reflect the changed messages so derbyall passes. Also, I don't know what gotchas might be out in the locale files -- would be another thing to follow up on. Anything else, derby developers? also that I may find bugs in the messages that would require a redo of the documentation... In my opinion, the docs (including any doc patches submitted) should be changed to match the code. -jean
Re: [jira] Commented: (DERBY-296) Document
Here's a text file that might help...it litst all the
messages with changes, and then the old and the new
version.
By the way, I am currently away on vacation, and my
access to email is limited. Just wanted to explain
why you might not get responses from me on various
items of discussion from time to time. I may not be
able to get to topics that people address to me until
I get back in a few weeks, but I will do my best.
--- David Van Couvering [EMAIL PROTECTED]
wrote:
I could do this; every time I talk to customers they
hammer into me that
clear and helpful error messages are key.
It would *really* help if I knew which message texts
were modified in
the doc. Is it limited to the Derby-specific
messages with SQLStates
starting with X?
Would I submit this as an independent patch to the
same JIRA item? Note
also that I may find bugs in the messages that
would require a redo of
the documentation...
David
Jean T. Anderson wrote:
David Van Couvering wrote:
I would agree... I think the right thing to do
would be to fix the code.
David
is that an offer? :-)
-jean
Jean T. Anderson (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717
]
Jean T. Anderson commented on DERBY-296:
Regarding this:
During my work, I discovered that many of the
messages could use
some spellchecking, grammar checking, etc.
Rather than document them
this way, I corrected them. At some point a
separate JIRA issue
should be made, and someone should undertake
the task of fixing the
actual message strings to reflect the correct
grammar, spelling,
punctuation, etc. used in this document.
I'm concerned users might be confused if the
error message an
application spits out does not exactly match the
error message string
documented in the Reference Manual.
I think this work shouldn't be committed until
doc matches code
(whether it involves changing the messages in
this patch or modifying
the code to match these).
Document
Key: DERBY-296
URL:
http://issues.apache.org/jira/browse/DERBY-296
Project: Derby
Type: Task
Components: Documentation
Environment: all
Reporter: Jeff Levitt
Assignee: Jeff Levitt
Priority: Minor
Attachments: derby296.zip
I've spent some time compiling a list of error
messages for Derby,
to expand on the error messages section
currently in the Reference
Manual. I am about ready to submit a candidate
patch, and I am
opening up a JIRA issue to contain it.
Original: 0100E|XX Attepmt to return too many result sets
Changed to: XX Attempt to return too many result sets.
Original: 22014|The start positon for LOCATE is invalid; it must be a positive
integer. The index to start the search from is '{2}'. The string to search
for is '{0}'. The string to search from is '{1}'.
Changed to: 22014|The start position for LOCATE is invalid; it must be a
positive integer. The index to start the search from is '{2}'. The string to
search for is
'{0}'. The string to search from is '{1}'.
Original: 22019|Invalid escape sequence, '{0}'. The escape string must be
exactly one character. It can not be a null or more than one character.
Changed to: 22019|Invalid escape sequence, '{0}'. The escape string must be
exactly one character.It cannot be a null or more than one character.
Original: 25501|Unable to set the connection read only property in an active
transaction.
Changed to: 25501|Unable to set the connection read-only property in an active
transaction.
Original: 40XD1|Container was opened in read only mode
Changed to: 40XD1|Container was opened in read-only mode.
Original: 40XD2|Container {0} cannot be opened, either it has been dropped or
is non-existant
Changed to: 40XD2| Container {0} cannot be opened; it either has been dropped
or does not exist.
Original: 40XT4|An attempt was made to close a transaction that was still
active, transaction has been aborted.
Changed to: 40XT4|An attempt was made to close a transaction that was still
active. The transaction has been aborted.
Original: 40XT6|Database is in quiescent state, cannot activate transaction.
Please wait for a moment till it exits the quiescent state.
Changed to: 40XT6|Database is inactive and cannot activate the transaction.
Please wait for
a moment until it exits the inactive state.
Original:40001|A lock could not be obtained due to a deadlock, cycle of locks
waiters is:
{0}The selected victim is XID : {1}
Changed to: A lock could not be obtained due to a deadlock, cycle of locks and
waiters
is: {0} The selected victim is XID :{1}.
Original: 42601|ALTER TABLE statement can not add an IDENTITY column to a
table.
Changed to: 42601|ALTER TABLE statement cannot add an IDENTITY column to a
table.
Re: [jira] Commented: (DERBY-296) Document
Great, thanks Jeff!
David
Jeff Levitt wrote:
Here's a text file that might help...it litst all the
messages with changes, and then the old and the new
version.
By the way, I am currently away on vacation, and my
access to email is limited. Just wanted to explain
why you might not get responses from me on various
items of discussion from time to time. I may not be
able to get to topics that people address to me until
I get back in a few weeks, but I will do my best.
--- David Van Couvering [EMAIL PROTECTED]
wrote:
I could do this; every time I talk to customers they
hammer into me that
clear and helpful error messages are key.
It would *really* help if I knew which message texts
were modified in
the doc. Is it limited to the Derby-specific
messages with SQLStates
starting with X?
Would I submit this as an independent patch to the
same JIRA item? Note
also that I may find bugs in the messages that
would require a redo of
the documentation...
David
Jean T. Anderson wrote:
David Van Couvering wrote:
I would agree... I think the right thing to do
would be to fix the code.
David
is that an offer? :-)
-jean
Jean T. Anderson (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717
]
Jean T. Anderson commented on DERBY-296:
Regarding this:
During my work, I discovered that many of the
messages could use
some spellchecking, grammar checking, etc.
Rather than document them
this way, I corrected them. At some point a
separate JIRA issue
should be made, and someone should undertake
the task of fixing the
actual message strings to reflect the correct
grammar, spelling,
punctuation, etc. used in this document.
I'm concerned users might be confused if the
error message an
application spits out does not exactly match the
error message string
documented in the Reference Manual.
I think this work shouldn't be committed until
doc matches code
(whether it involves changing the messages in
this patch or modifying
the code to match these).
Document
Key: DERBY-296
URL:
http://issues.apache.org/jira/browse/DERBY-296
Project: Derby
Type: Task
Components: Documentation
Environment: all
Reporter: Jeff Levitt
Assignee: Jeff Levitt
Priority: Minor
Attachments: derby296.zip
I've spent some time compiling a list of error
messages for Derby,
to expand on the error messages section
currently in the Reference
Manual. I am about ready to submit a candidate
patch, and I am
opening up a JIRA issue to contain it.
Original: 0100E|XX Attepmt to return too many result sets
Changed to: XX Attempt to return too many result sets.
Original: 22014|The start positon for LOCATE is invalid; it must be a positive integer. The index to start the search from is '{2}'. The string to search for is '{0}'. The string to search from is '{1}'.
Changed to: 22014|The start position for LOCATE is invalid; it must be a positive integer. The index to start the search from is '{2}'. The string to search for is
'{0}'. The string to search from is '{1}'.
Original: 22019|Invalid escape sequence, '{0}'. The escape string must be exactly one character. It can not be a null or more than one character.
Changed to: 22019|Invalid escape sequence, '{0}'. The escape string must be exactly one character.It cannot be a null or more than one character.
Original: 25501|Unable to set the connection read only property in an active transaction.
Changed to: 25501|Unable to set the connection read-only property in an active transaction.
Original: 40XD1|Container was opened in read only mode
Changed to: 40XD1|Container was opened in read-only mode.
Original: 40XD2|Container {0} cannot be opened, either it has been dropped or
is non-existant
Changed to: 40XD2| Container {0} cannot be opened; it either has been dropped
or does not exist.
Original: 40XT4|An attempt was made to close a transaction that was still
active, transaction has been aborted.
Changed to: 40XT4|An attempt was made to close a transaction that was still
active. The transaction has been aborted.
Original: 40XT6|Database is in quiescent state, cannot activate transaction. Please wait for a moment till it exits the quiescent state.
Changed to: 40XT6|Database is inactive and cannot activate the transaction. Please wait for
a moment until it exits the inactive state.
Original:40001|A lock could not be obtained due to a deadlock, cycle of locks waiters is:
{0}The selected victim is XID : {1}
Changed to: A lock could not be obtained due to a deadlock, cycle of locks and waiters
is: {0} The selected victim is XID :{1}.
Original: 42601|ALTER TABLE statement can not add an IDENTITY column to a table.
Changed to: 42601|ALTER TABLE statement cannot add an IDENTITY column to a table.
Original: 42610|All the arguments to the COALESC/VALUE function can not
Re: [jira] Commented: (DERBY-296) Document
David. If you are planning on doing this and making a pass throughout the code to make sure the correct SQLState is set correctly (not just correcting the message property files), it might be worthwhile to add some type of marker comment in places where the code will need to be changed for JDBC 4 in order to bring the SQLExceptions being thrown in line with the changes for the new SQLExceptions based on the SQL state class values. By at least having an easy to find comment, it will make it easier to go back and do the retrofit. Of course this only makes sense if you are going to make a pass through the entire derby codeline for this adventure. just a thought if you are looking to have some more fun 8-) David Van Couvering wrote: I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Would I submit this as an independent patch to the same JIRA item? Note also that I may find bugs in the messages that would require a redo of the documentation... David Jean T. Anderson wrote: David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
Re: [jira] Commented: (DERBY-296) Document
I would agree... I think the right thing to do would be to fix the code. David Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
Re: [jira] Commented: (DERBY-296) Document
David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
Re: [jira] Commented: (DERBY-296) Document
I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Would I submit this as an independent patch to the same JIRA item? Note also that I may find bugs in the messages that would require a redo of the documentation... David Jean T. Anderson wrote: David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
