[Openroad-users] Dates in Openroad/Ingres

[Simon Lovell]

The difference in Ingres versions you are seeing is because support for years before 1582 or thereabouts was added in 2.5.  Not quite sure why you can save the data against a 2.0 back end in OpenROAD, but it's not important.

I once added such a validation to every date field in the application using a bulk update tool.  As you might expect, this caused a few problems when date fields were used for times or intervals, and these had to be manually found and fixed, but you might be able to detect these instances by looking at the format string, if you have one.  Broadly, it worked like this: Use get_appl(...), Find all frames, search through the form for any fields with a data type of date, and for those fields, find the setvalue event and add some code, and an include script.  If there was no setvalue event, it had to be added after the initialize block.

I'm not sure if there's a way to change it in one place with a global effect.


-----Original Message-----
From: "Stijn Caroen" [Stijn.Caroen at ap2.be]
Date: 08/02/2007 01:21 AM

Hello,
 
We have a recurring problem with a client where users need to enter date values in an Openroad application.  For instance, they will enter a date value â01C01/04/0206â01D instead of â01C01/04/2006â01D.  These mistakes will generate errors in some batchs that run during the night.  Some tests have shown that:
-          If you enter such a date in Ingres version Ingres II 2.0 via the terminal monitor (sql command)
o        Error message: not a valid year
o        Same error message if you use for instance 01/04/206
-          If you enter such a date in Ingres version R3 or 2006 via the terminal monitor (sql command)
o        No error message, the data is saved
-          If you enter a date in a date field in Openroad and you save your data
o        Using a database with version Ingres II 2.0 or Ingres R3 or Ingres 2006
§         No error message, the data is saved
 
I have several options I can already use:
I could add a rule on every date attribute in the database that will not allow saving this kind of data but I donâ019t like this solutionâ026
Create your own check in Openroad for date type validation, discussed in the sections below
 
 
Openroad provides us the possibility to change the procedure that is used when a value given by a user does not correspond to the type of the field.  For exemple, a user that enters a string in an integer field will generate a type definition error.  This error can be handled by your own procedure (bypassing the error message given by Openroad = override DataEntryErrorHandler of the frame).
 
The exported application in attachment (OR 2006) contains a user frame where I use my own type violation procedure (DataEntryErrorHandler).  As an extra, I added an event to the frame that can call a generic procedure that sees to it that there is no date entered by the user that is lower than â01801/01/1900â019.  If you launch the frame, you will see that is not possible to perform any actions on other fields when you have entered a wrong date in the first entryfield.
 
Using this option, I would need to add the event into every frame that uses date fields (which would all call the same procedure for type checking).
 
 
My question: is it possible in Openroad to extend the type validation procedure used by the Openroad runtime?  For instance, if you enter a date that is lower than â01801/01/1900â019, the validation does not pass and Openroad shows an error message (or your own procedure is called for handling type validation errors).
 
What I mean is, that at the entry point of the application, you can add one call that allows to add extra checks for type validation that will be active for the whole application session.  This can bypass the need to add extra code at each frame like in the option discussed above (the code is not generated with this particular client and there are quite a number of frames).
 
Or does anyone have another idea?
 
 
Cheers,
Stijn Caroen
AP&P, Belgium