Creating central message files/objects has the added advantage of a much
simpler locale support - they're just resource files, and they're NOT
embedded throughout the code.
Finally, if you do want to have some kind of error classification beyond
the SQL code, it could be encoded in the error
At 03:28 21/03/01 +, Thomas Lockhart wrote:
Creating central message files/objects has the added advantage of a much
simpler locale support - they're just resource files, and they're NOT
embedded throughout the code.
Finally, if you do want to have some kind of error classification beyond
Thomas Lockhart [EMAIL PROTECTED] writes:
So we need some good error numbering scheme. Any ideas?
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible?
Good point, but I
So we need some good error numbering scheme. Any ideas?
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible?
Yes, it defines at least a few dozen char(5) error codes.
Zeugswetter Andreas SB writes:
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible?
Yes, it defines at least a few dozen char(5) error codes. These are hierarchical,
[EMAIL PROTECTED] wrote regarding
Re: AW: [HACKERS] Re: More on elog and error codes:
Zeugswetter Andreas SB writes:
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible
So we need some good error numbering scheme. Any ideas?
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible?
- Thomas
---(end of
