Catching information about debug and errors 1

[LonnieJohnson]

I have an app where I was programmatically saving data using a dao recordset to a sql server backend. One of the fields I was updating had a length of 100 chars. The user was trying to save more than that. The system raised a message box with a debug button. When you click it an error message box appeared saying that the field’s length was being exceeded and highlighted the line in code where it was trying to update.

My question, is there a way to report with a message box anything in that highlighted line?

Thanks.

ProDev, Builders of Affordable Software Applications
Visit me at ==>

http://www.prodev.us

May God bless you beyond your imagination!!!

 

[smedvid]

Perhaps a Before Save event; you can write some code to validate field lengths in a function. I've done this before (many moons ago) Use a table with FieldName and Length; then just read through all values in a loop.
htwh,

Steve Medvid
IT Consultant & Web Master

http://www.saveourfarm.com

Chester County, PA Residents
Please Show Your Support...

 

[LonnieJohnson]

We actually did something similar to that. We hard coded the legths in the module behind the form and validate before saving. The problem I was trying to eliminate was putting the lengths in another location to avoid having to change them in the actual table and the place where it checks for validation. I guess I could write something that gets the table def from the sql server and determines the length.



ProDev, Builders of Affordable Software Applications
Visit me at ==>

http://www.prodev.us

May God bless you beyond your imagination!!!

 

[MichaelRed]

but, what do you actually want to do? You can easily just truncate the value to the field length (e.g. Left(varIn, Len). You can also esily chevk the length before the save and use an inputbox to advise the user of hte exceeding the length and allow them to edit to fit. If you need to change the field size, it will taks a bit more effort.




MichaelRed

 

[LonnieJohnson]

Hello MichaelRed. I haven't had the pleasure of talking to you in a while.

The value they are saving comes from a drop box. They are medical diagnosis codes. We think we have the longest one recognized and set the field accordingly. Then they add another code to the list and it exceeds the field length. We change the field length in the table but since we have this hard coded value, then we have to change the hard coded validation in the applications. There is more than one application that accesses this field. So it is would need to be changed in multiple places.

What I was trying to accomplish was to have a generic validation that would be able to identify the field without hard coding. I think what I was asking initially was a bit much. Which was to be able to read the line that the code stopped on and concatenate it into a message so the developer would know what field it failed on without having to hardcode.

I am probably not making myself clear. Bottom line. I hate hard coding. Always looking for other ways around it.


ProDev, Builders of Affordable Software Applications
Visit me at ==>

http://www.prodev.us

May God bless you beyond your imagination!!!

 

[MichaelRed]

A) size the field somewhat larger than the longest existing entry by some (reasonable?) amount. Say 10 to 15%. I assume you have already done that part? Almost always a useful approach.

B) assuming the 'psrt' of the highlit is actually a variable? if you can get all of the places it is accessed to use a common name, then you could just report the variable content to the admin. Even if the various accesses do not use the same var name / approach, visitiing each place that writes to the record.field should be sufficient to generate an error trap routine and have that place the information into static storage. I would probably opt for a new copy of the recordset making all possible suspect fields as either the max allowed or a memo field. You (or any admin could look at the new rs as often as necessary / desired. take appropiate action (e.g. resize the field) and delete the entry. I have generated procedures which e-mail users of important events based on this approach.

This process occurs each time the user(s) start the app. It checks for the condition(s), generates an e-mail to them with the requsite information.

Newer versions of all languages thet I use at least alert the user that the process is doing hte e-mail, but users are generally tolerant of the dialog boxes to permit the messages to be generatd and sent. The process does slow the start up of the app, but this has not been an issue, as the apps are somewhat cumbersome anyway.




MichaelRed

 

[LonnieJohnson]

Thanks you Sir. Choice "A" is what we thought we had done and increased it even more now. This is very useful information.



ProDev, Builders of Affordable Software Applications
Visit me at ==>

http://www.prodev.us

May God bless you beyond your imagination!!!