Better error message
Michael Gould
data error for more than a day now. The error messages that come from the
database are quite cryptic. For example
1. Primary key for table 'Payroll' is not unique.
It would be nice if the offending row would be available for the error
message
2. Value -157.25 out of range for destination.
It would be nice to know what the destination table and variable name is.
When you are processing 10,000 rows against multiple tables it would be nice
to know what the column and table is. Sure you can do request level logging
but when the application is in production and you've never seen this error
in 10 years of the program running and every other user ran this application
without any problems it would be helpful to get as much information as
possible in the error message
Best Regards
Michael Gould, Manager Information Technology
First Coast Logistics Services, Inc.
All Coast Intermodal Services, Inc.
Ivan T. Bowman [Sybase iAnywhere]
We have been discussing ways that we can improve error reporting. I also
find it difficult to find the cause of some error messages and I wish they
provided more information.
One of the concerns that has come up in our discussions is that there may be
a performance penalty to track context information in order to provide more
useful information. In some cases we might need to forego optimizations that
would destroy context or we would at least need to be quite careful about
tracking the context through the optimization. For example, with constant
folding and common sub-expression elimination, a single expression might
represent a number of different expressions in the original query.
Do you think that it would be better to have this extra information
available at all times (even if there are some performance consequences) or
would you rather the extra information were only collected in certain modes
of running (for example, this could be turned on if you have a reproducable
problem).
Thanks,
--
Ivan T. Bowman
SQL Anywhere Research and Development
[Sybase iAnywhere]
"Michael Gould" <mgo...@firstcoast.net> wrote in message
news:49eb2c28@forums-1-dub...
Justin Willey
I really support the idea of having this sort of information available. As
Michael says, it can take for ever to track down and the server already
"knows" the answer.
In my experience, this kind of problem happens most in development,
scripting and data transfer situations and is normally reproducable, so from
my point of view, the option of having a "Try doing that again but tell me
what the problem is this time" option would be ideal.
Justin Willey
"Ivan T. Bowman [Sybase iAnywhere]" <ibo...@ianywhere.NOSPAM.com> wrote in
message news:49ec6725@forums-1-dub...
David Fishburn [Sybase]
sybase.public.sqlanywhere.product_futures_discussion:
...
ITB> Do you think that it would be better to have this extra information
ITB> available at all times (even if there are some performance
ITB> consequences) or would you rather the extra information were only
ITB> collected in certain modes of running (for example, this could be
ITB> turned on if you have a reproducable problem).
I personally favour turning this on when required.
Performance, performance, performance is the standard mantra.
Reducing optimization efforts will impact this.
From a "runtime" perspective, we only need to find the "where".
Turning on a option at runtime to locate it, is usually all that is
required.
My 2 cents.
--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng11 -v).
EBFs and Maintenance Releases
http://downloads.sybase.com/
Developer Community / Whitepapers
http://www.ianywhere.com/developer
Case-Express - to report bugs
http://case-express.sybase.com
CodeXchange - Free samples
http://ianywhere.codexchange.sybase.com/servlets/ProjectDocumentList
Documentation
http://dcx.sybase.com/
Volker Barth
messages will typically arise in non-standard situations and therefore
should not impact the general performance.
I would prefer a (connection-level?) option over a server startline
parameter as this will often appear on production systems where restarting a
server just to include a "give me more error information"-flag is not
possible.
Regards
Volker
"Ivan T. Bowman [Sybase iAnywhere]" <ibo...@ianywhere.NOSPAM.com> wrote in
news:49ec6725@forums-1-dub...
Breck Carter [TeamSybase]
messages, rather I believe you should concentrate on individual
messages that have proven to be troublesome.
Michael has hit upon two absolute classics...
>1. Primary key for table 'Payroll' is not unique.
>It would be nice if the offending row would be available for the error
>message
>2. Value -157.25 out of range for destination.
>It would be nice to know what the destination table and variable name is.
Are these particular contexts are somehow hidden by optimizations?
When error 1 is detected you do not KNOW what the offending value is?
When error 2 is detected you do not KNOW what the table.column or
variable is?
=====
I also don't like the idea of making it optional, since that seems to
be an invitation to modal execution, "debugging mode" that catches no
errors because it's a tiny test database, versus "optimal mode" that
runs like a rocket but says "Some Kind Of Error Happened Somewhere"
when things go awry :)
Once an error has *occurred*, if extra cycles are required to dig up
the true story, then that's OK with me... that connection is already
having a Bad Day.
=====
My personal favorites are -656 and -660 where it seems that the actual
underlying remote server error codes are lost, only the (often less
than helpful) error message text survives.
Breck
On 20 Apr 2009 05:14:29 -0700, "Ivan T. Bowman [Sybase iAnywhere]"
<ibo...@ianywhere.NOSPAM.com> wrote:
>Thank you for raising this issue.
>
>We have been discussing ways that we can improve error reporting. I also
>find it difficult to find the cause of some error messages and I wish they
>provided more information.
>
>One of the concerns that has come up in our discussions is that there may be
>a performance penalty to track context information in order to provide more
>useful information. In some cases we might need to forego optimizations that
>would destroy context or we would at least need to be quite careful about
>tracking the context through the optimization. For example, with constant
>folding and common sub-expression elimination, a single expression might
>represent a number of different expressions in the original query.
>
>Do you think that it would be better to have this extra information
>available at all times (even if there are some performance consequences) or
>would you rather the extra information were only collected in certain modes
>of running (for example, this could be turned on if you have a reproducable
>problem).
>
>Thanks,
--
Breck Carter http://sqlanywhere.blogspot.com/
RisingRoad SQL Anywhere and MobiLink Professional Services
breck....@risingroad.com
krisztian pinter
<NOSPAM__br...@gmail.com> wrote:
> I also don't like the idea of making it optional, since that seems to
> be an invitation to modal execution, "debugging mode" that catches no
> errors because it's a tiny test database, versus "optimal mode" that
> runs like a rocket but says "Some Kind Of Error Happened Somewhere"
> when things go awry :)
also note, that there are the heisenberg kind of bugs, that tend to
disappear when observed. it is quite possible that the optimizations
themselves expose a bug, in which case, it might only appear in the
production system.
Breck Carter [TeamSybase]
Exception-Driven Development
http://www.codinghorror.com/blog/archives/001239.html
...so I could have included this quote:
"Although I remain a fan of test driven development, the speculative
nature of the time investment is one problem I've always had with it.
If you fix a bug that no actual user will ever encounter, what have
you actually fixed? While there are many other valid reasons to
practice TDD, as a pure bug fixing mechanism it's always seemed far
too much like premature optimization for my tastes. I'd much rather
spend my time fixing bugs that are problems in practice rather than
theory."
In other words, deal with Michael's cases :)
Breck
On 20 Apr 2009 15:01:12 -0700, "Breck Carter [TeamSybase]"
Michael Gould
In my case this happened in production. It ended up being a data issue
which I've now fixed the entry so it can't happen again, but this
application is 10 years old. The particular table that this happened on has
about 10,000 rows a day added so finding the information was extremely
difficult. I spent close to 20 hours trying to track this down. The
procedure that error message alluded to wasn't the actual procedures that
the error occured in but one that it called.
Best Regards
Michael Gould
"Justin Willey" <g...@nospamatall.iqx.co.uk> wrote in message
news:49ec68b6$1@forums-1-dub...
Michael Gould
I like the option approach for debugging purposes. I really don't care if
it is a connection level parameter or not as long as I can turn it on or off
via a statement like we can logging.
Best Regards
Michael Gould
"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> wrote in message
news:49ec84a2@forums-1-dub...
Bill Aumen
installations (by remote, I mean we take a seaplane, followed by a skiff,
followed by wading ashore to get to the site). So, error logging is REALLY
valuable to us so we can connect remotely and see what the user meant by "I
pressed save and got some kind of error message."
so a few milliseconds of overhead with each request is nothing compared to
trying to track down the details after the fact. Our big problems occur in
Production, development and debugging when we are the ones pressing the save
button is comparatively a no-brainer.
Here is a sample of the logging we get from our PowerBuilder apps via the
code we put in the dberror event. You will see it tells us the data content
as well as the executing code. This same capability for all our SQL Anywhere
code is what we are looking for.
User:baumen MachineName:T61BILL 22-Jan-2009 13:43:48
AppVersion:11.03.00 BuildDate:20-Jan-2009 13:39 DSN:CfsBestPractice
DBN:CfsBestPractice GlobalDatabaseID:1
Error: -193 A database error has occurred.
Database error code: -193
Database error message:
SQLSTATE = 23000
[Sybase][ODBC Driver][SQL Anywhere]Primary key for table 'intk_intake' is
not unique : Primary key value ('50000002')
No changes made to database.
INSERT INTO "intk_intake" ( "intk_id", "fi_intake_id", "cr_registry_id",
"syusr_id", "intk_call_received_date", "intk_call_received_time",
"intk_caller", "intk_children_safe", "intk_response_time",
"intk_concern_summary", "intk_close_date", "intk_close_summary",
"intypu_code", "intk_recommendation", "intk_notify_caller_of_outcome",
"inclose_code" ) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )
DataObject=d_intk_list, Buffer=Primary!, Row=1
intk_id = 50000002
fi_intake_id = 875
cr_registry_id = NULL
syusr_id = baumen
intk_call_received_date = 1/22/2009
intk_call_received_time = 11:00:00
intk_caller = NULL
intk_children_safe = U
intk_response_time = 72hours
intk_concern_summary = hi
intk_close_date = NULL
intk_close_summary = NULL
row_id = 178
row_status =
intypu_code = reportablecircumstance
intk_recommendation = NULL
risk_assessment_date = NULL
safety_plan_date = NULL
intk_notify_caller_of_outcome = no
risk_assessment_id = NULL
safety_plan_id = NULL
row_specific_modified = NULL
inclose_code = NULL
Window: w_file
Object: u_aumcon_dw
Event: dberror
Line: 48
"David Shuman" <d.sh...@att.net> wrote in message
news:4a2b4ece$1@forums-1-dub...
>
> Ivan:
>
> First any error message should provide at a minimum
> the name script being executed (PROCEDURE, TRIGGER, SYSTEM TRIGGER,
> etc
> the statement being executed (including the data values for
> variables)
> If possible the actual row being accessed (table and primary key)
> when appropriate.
>
>
> Second as to when to provide said information.
> I understand the viewpoint to limit this to a test environment for
> performance reasons
> BUT when a production error occurs recreation is not always
> possible (lack of a known method)
> THEREFORE, it is critical to get the information at the time of
> occurance.
> It also facilitates debugging and correction of issues to
> restore the application quicker
>
>
> Third application profiling does not in any way provide a reasonable
> workaround as has been suggested.
> To get any detail you must log all SQL statement
> (NO PARAMETER OR KEY DATE INCLUDED in this option
> so you can only guess which rows are
> being processed)
> IT generates so much data that the detail window will not allow
> the last executing statement to be viewed
> (how do you recover when the selection window overflows
> the number of rows and goes blank?)
> (without playing excessively with times or other selection
> criteria)
> Maybe an option to reverse the sequence of the data to the last
> statement first could help here.
>
>
> Fourth As I recall the Sybase Sql Server supported a second text field
> with error messages with greater detail
> If this option is used -- those parsing current error messages will
> not be affected by the additional information
> - those wishing access will merely
> need to deal with the additional text variable in their error processing.