Date field not under 1753 in Native - UPDATED
When I was on the plane to New York a few weeks ago (After Convergence, but before Directions), I wrote this blog post ... . I forgot to put it online though. Better late then never 
.
At this moment, I'm sitting on the plane to New York, together with my wife. We'll spend some time sightseeing until I'm heading to Orlando to this year's Directions. I was wondering ... What will I do for the next 8 hours. After a horrible movie, I decided to browse through Codeunit 1 (how pathetic am I ... don't answer).
Then I was thinking of the last change I did: the "date picker trick" you can find on my blog as well.. . Why not another trick. Why not avoiding dates below 1753 to be able to get them into SQL Server afterwards. Seemed like a pretty easy thing to do.
I opened codeunit 1 (5.0 SP0) and started working. Soon already, I bumped into one nasty little thing... as soon as I called an ERROR in function "MakeDateText", the system reacted quite odd. First time, it wouldn't show me the error, second time it did show me the error. And after that, it kept on showing the error on very strangs moments: when editing in the C/AL editor, changing text, ... .
A very simple test I did was putting one line of code in that function (the ERROR-statement), and it showed me the exact same behaviour all the time.
Was it my headache that I got during that very bad movie, or is it the fact that my laptop is running in "power saver" mode ... I guess not. I concluded that this was a no-can-do (but hope someone can proove otherwise) ... . Unfortunately 
. Anyway ... Three more hours to go until New York 
.
**** UPDATE ****
Thanks to Kine's comment, I was able to create a somewhat workable solution.
It's quite simple. Just add following code at the beginning of the MakeDateText-function in Codeunit 1:
//*** Waldo BEGIN
IF EVALUATE(Date,DateText) THEN BEGIN
IF Date < 01011753D THEN BEGIN
DateText := '';
MESSAGE('Your Error Message');
ERROR('');
END;
END;
//*** Waldo END
Off course, you can change the documentation lines .
It was a problem to raise the error in a proper way. I mean, when just raising the error, the message poped up at the proper time, but still, the value was filled in. As I didn't have the previous value of the field, I decided to empty the field, and then raising the error. Other solutions could be:
- to switch the year to the current year
- to work with a CONFIRM
- to create some logic to propose the most probable date
- ...
Anyway, hope it's useful.