Date field rule doesn't work

[Ronald Anusiewicz]

I have a table with numerous field rules defined. For the date field, I have a simple expression set as Date(). When the cursor enters the field, todays date comes into view. When I leave the field, the field goes blank.

I've tried just about every setting that makes sense and a few that do not. The end result is always the same. I have other fields, none date, that work just fine. I have no problem entering a date. The default just keeps disappearing when the cursor moves to either the previous field or the next field.

TIA

Ron

[Tom Cone Jr]

RE: Date field rule doesn't work

Ron,

Here's a simple debugging technique to help narrow the range of possible culprits.

1) Open the table using the default form. Enter a new record. If the field behaves correctly that's a good indicator the field rules are ok, and that your original problem lies in the form, possibly in actions or events you've programmed there.

2) My guess is that the problem will repeat itself using the default form for the table. This is a good indicator the problem is not in your custom form, but lies in conflicting field rules. The skip setting in data entry is a likely candidate. In any event, go through all the field rules for the field in question.

If neither of these leads to a solution, I suggest you compact your database, close alpha five, and the reopen Alpha Five and the database.

-- tom

[Ohlen Cartmell]

RE: Date field rule doesn't work

I assume you've set this as a default field in field rules. Try setting the options to fill the field at the start of data entry and set the skip rule to .t. . That way the cursor never enters the field and the value is set when a new record is begun.

[Ronald Anusiewicz]

RE: Date field rule doesn't work

Thanks again Tom.

Yes, it worked on the default form. Actually, I'm using an embedded browse on the form.

I traced the problem to what I believe is a bug in Alpha 5. Under properties, the format choice has to be none for the default to work. I didn't try all of the choices, but 12-31-1999 bombs out. As it turns out, selecting none give you 12-31-1999.

This was easily duplicated on a test table.

Ron

[Tom Cone Jr]

RE: Date field rule doesn't work

Ron,

I've been able to confirm the problem here.

If the default value (by field rule) is date(), and the box to 'Set default at start of data entry' remains unchecked, then the field gets blanked when the user tabs through the column in an embedded browse, if the user has specified a format setting for the column in the embedded browse.

If you 'Set default at start of data entry', the format settings for the column don't seem to mind, and the value is retained when the user tabs through the column.

-- tom

[Nip Lewis]

RE: Date field rule doesn't work

What if you have 2 fields, one for adding a new record and the other to change date when a change is made in a particular record. i.e 2 fields

chgdtt
addtt

Right now when I add a new record the the change date also records today's date If I remove the default in the event rule I have to type in the date the change is made. Is there a way to have the date something in a record is changed. Any help would be appreciated.

Nip Lewis

[Tom Cone Jr]

RE: Date field rule doesn't work

Nip,

Field rules for your table are enforced whenever you do data entry through a form.

If you want to know both when a record was initially created and when it was last modified, you have to use two fields, as you are currently doing.

The xbasic mode_get() command statements can be used to determine whether the user is entering a new record, or changing an existing one.

You will either have to modify the field rules to make them conditional, based on the table's mode,

or

delete the field rules and use form level events instead.

The latter may be easier for you. For example, you could put a button on your form to 'Save Changes', and the button's script could update the correct field with today's date, depending on whether the table is enter mode or in change mode. If you do this, then you have to prevent the user from saving changes without pushing the button.

-- tom

[Dan Blank]

RE: Date field rule doesn't work

Actually this is easy to do, I do it all the time with two time fields, and two user login fields. This way I have an informal audit trail of who changed a record and the date and time they changed the record.

For the "addtt" field in Field Rules|Data Entry set the default value to a simple default expression equal to date(), and check the box to 'Set default at start of data entry'.

For the "chgdtt" field in Field Rules|Field Types set the estended field types to a calculated field and in the calculated field expression box enter DATE().

This works like a charm for me.

Dan

[Tom Cone Jr]

RE: Date field rule doesn't work

Dan,

thanks! That's much easier than the approach I was describing. Your idea works well in most cases. However, if it's important to track that a change was made on the same date that the record was entered your idea won't solve the puzzle. Why? because the calc field rule supplies the current date to the lastupdated field when the record is created, and when it's changed. Changes on the date the record was created will be indistinguishable from records that have no changes on the date they were entered. However, in many cases that's entirely ok, because changes on the same day as data entry are probably only just data entry error fixes.

Thanks again.

-- tom

[Dan Blank]

RE: Date field rule doesn't work

Well you are correct for the most part. This is why I use the time field. The time is set in the field rules the same as the date field rules. So if the time is the same for the two fields, it is when the record is created. If the time is different, then the TimeEntered field is when the record is created, and the TimeChanged field is the time when the record is changed.

And I also use a log on screen so I actually have the name of the person who created the record and the name of the user who changed the record. (Field rules set the same).

The flaw is if one person changes the record, and then an hour later another person comes along and changes the record again, then I lost the actions of the first record change. However, this is just an informal audit trail for simple problem solving. If it was critical data I would use the "Create an Audit Trail" that Peter Wayne describes.

Dan