Question..

Why is ATRECORD set as a blank record when the form is created?

ie I have a checkbox as part of my form and in the create event the atrecord is all null with @fm's and a 0 in the checkbox position.

other forms just shows the @fm's with no data

If Atrecord is more reliable then @record then should it not be null for a new record?

Curious!!

Gerry

Hi Gerry,

Curiosity eh? Remember what happened to that cat…

ATRECORD was intended for the following:

1) To give an accurate point-in-time view of the data contained in the controls combined with any data in the record but not bound to a control

2) To allow data columns not bound to a control to be updated when used with Set_Property if the WRITEATRECORD property was also set.

3) To automatically populate data-bound controls from the record specified by the property.

(Contrast this with the RECORD property that does none of these things.)

Therefore it will never return a null record because that's not the intention.

FYI In the next release ATRECORD/WRITEATRECORD has been deprecated (but not removed!) by a new ROW property to just simply things a bit:

ROW property

Gets or sets data associated with the primary table for the specified data-bound form and updates its data-bound controls.

When getting the property, the data is extracted directly from the controls on the form and merged with a cached version of the data row that was read from disk during the READ event.

When setting the ROW property, the cached copy of the form's data row is replaced and then the data-bound controls are automatically populated from that. The form's WRITEMODE property is automatically set to "WriteEntireRow" (i.e. WRITEATRECORD ⇒ True)

By default the WRITE event of a form only updates the columns in the database table that are bound directly to controls on the form – any data columns that are not bound to a control are ignored by the write processor. The intent behind this default behavior is to prevent data corruption in cases where different forms load different columns from the same row at runtime. If each form updated the non-bound columns during the write process it would be possible to overwrite new data with stale data.

However, this "multiple forms per single row" model is not as common as a "single form – single row" model, and there is an expectation that when setting the contents of the entire row at runtime the following is true:

a) Any data-bound controls are updated from the contents of the new row.

b) Any columns not bound to controls will still be written back to disk.

The ROW property fulfills both expectations in a single operation, whereas previous versions of OpenInsight would need to use the ATRECORD property and the WRITEATRECORD properties together.

(This emulates the functionality of setting the @Record variable for a data-bound form in an Advanced Revelation application which would automatically populate the data-bound prompts on screen.)

There is also a new "NEWRECORD" property that is set to TRUE if the currently loaded record is a new one.

Regards

Carl Pates

Wow

Thanks Carl

Seems like you have been doing some other work apart from answering my questions

Look forward to the new update..

Appreciate the detailed answer

Gerry

View this thread on the Works forum...