Canceling methodolgy for sets

[danh]

I am trying to understand the proper methodology of undoing (canceling) changes to records in a form base on a set, including canceling new records. When I say records, I am referring to the complete form, including all the data from all the tables. If I want to give the user the option of saving or canceling before moving to the next record or closing the form, I can do it just fine in a form based on a single table by using the following code in the 'CanSave' and 'CanExit' events.

dim vMode as C
vMode = parentform.Mode_Get()
	if vMode <> "VIEW" then
		dim vAns as N
		vAns = msgbox("Save?","You have made changes, do you want to save them before leaving?",UI_ATTENTION_SYMBOL+UI_FIRST_BUTTON_DEFAULT+UI_YES_NO_CANCEL)
		if vAns = UI_YES_SELECTED then
			'Yes selected,
			'do nothing, record saved automatically
		elseif vAns = UI_NO_SELECTED then
			'No selected
			topparent.cancel(.t.)
		elseif vAns = UI_CANCEL_SELECTED then
			'Cancel selected
			cancel()
		end if
	end if
end if

Alpha's help file says:

In almost every case, Alpha Five treats sets exactly like tables. You can create layouts and perform and save operations for a set. When entering data into a form designed for a set, the information is automatically placed into the correct table along with the necessary linking information.

But this code does not work for a form base on a set. Alpha saves (commits) the changes to the table for each table affected as you move around on the form. So, what is the proper method of canceling...

I'll use Alpha Sports for an example...

Open up Alpha Sports and open the invoice form,

on any existing invoice; add/change a credit card number in the credit card field,
then move down and add a line item to the invoice,
then move up and edit the price on an existing line item...

... now cancel all of the above... how do I do it?

Thanks, Dan

[Tom Cone Jr]

Re: Canceling methodolgy for sets

Dan, on your Invoice form example I'll wager the parent table record is saved automatically when focus shifts to a row in the items browse. Right? This is Alpha's way of assuring no loss in data. The same is true if you start a change in a row in the browse and then shift focus to a field on the form from the parent table. No data loss because the change is commited automatically.

Because the data is stored in separate tables I think Alpha's design choice is a good one. You wouldn't want the user entering child table records and then have the parent table record get cancelled, leaving orphans behind, for example. In many cases, too, the key field in the primary table is based on an autoincrement field rule. This value is not "fixed" until the primary table record is saved. What you see on screen is only a tentative or preliminary key field value and it will change if another user on the network saves their new primary table record before you.

So, you're asking a hard question. Basically you're saying you want to abandon the built in safeguards of the table by table commits and roll your own data entry sequences. This can be done of course, but it's a lot of work. Here are some ideas. Perhaps others will have better suggestions for you, too.

a) Do the data entry using temporary tables, providing the user with a button to push that will create (copy) records from the set's temporary tables to the real ones. I don't see a way this will work with an autoinc field rule in your real tables, but then you may want to roll your own autoinc sequences, too <grin>.

b) Use xdialogs and data entry fields that are bound to variables. Again, you probably will hve to roll your own autoinc sequence.

c) Force the user to push a button to begin edits. The button script would store the current records (primary and linked child) in arrays. Put a button on the form to cancel all edits. Have that button overwrite the edited records with original field values.

If you head down this path you will need to plan for undoing single record enters, edits, and deletes, as well as undoing composite record enters, edits, or deletes. Not an easy task.

In my own work I shift the responsibility to the user where possible. Before permitting focus to shift to an embedded browse I check the mode of the form and if it's not VIEW I ask the user to cancel or save edits before proceedings. Ditto when the user wants to shift focus away from an embedded browse. This prevents the "accidental" save that's built in by default.

-- tom

[danh]

Re: Canceling methodolgy for sets

Why would the data be lost when it is still on the screen? Wouldn't there be just as much chance of data lose on a form based on a single table? It's not committed until you go to the next record or close the form. That is all I want with a set. Why do I need to explain to my user (just for forms based on sets) that certain data is coming from multiple tables and therefore needs to be save individually? How does QuickBooks do it. I can change any part of an invoice, PO, Bill, etc, (existing or new) all day long, and turn around and cancel the whole thing. This was a problem in Access and I was hoping Alpha would be different. It creates a lot of work for the programmer to have to figure out a way around this, unless someone has a simple solution. I wonder what the Alpha programmers would say.

Dan

[Tom Cone Jr]

Re: Canceling methodolgy for sets

I'm sure the folks at Intuit worked very very hard to make things seem seamless. Perhaps others will have better suggestions for you. My guess is that you'd be happier with a form upon which all the objects were bound to variables, using a single event or button click to save or cancel all edits. This runs counter to the flow of typical Alpha Five forms. The design choice was made long ago to bind the form and its objects to the underlying data structures automatically, by default. This has many benefits. Unwinding a set based transaction is not one of them. -- tom

[DaveM]

Re: Canceling methodolgy for sets

edit: sorry Tom, I was slow typing with both fingers.


Dan,

You have the option as a programmer to make your own screen with all variables on it. copy the data from a file and then modify all you want. Once modified, you can the put the changes back in the table(s) or cancel and nothing is changed.
It is a lot of work, but you can do this.

If you work with alpha as it is with the drawn forms, you are kinda doing the same thing, but as soon as you do something(knowingly or not) to save it, it cannot revert back.

Now think of this. If you redo your sets to cascade/changes and deletes? for the cihild tables? It may help you. You can also setup to copy the previous record to a new one(button) and change as needed then copy changes back. You can have 2 sets with identical(but not the same tables) to post back and forth.

I am just giving methods here: I just delete what I don't want, but the delete button just marks the record so i don't see it again. Later, i may really delete it.

Another note:
If you had the same problem in access and alpha, it would be to presume that you will with anything else and since the programs are not going to change, the solution is..............?

I do have 2 out of a bunch of forms that have nothing on them but variables. There are reasons for it, but most of the time it is not as good.

EDIT: One more way, you can always copy all the fields into vars or an array and if you want to revert back, set it to a button to reput the data.

[Al Buchholz]

Re: Canceling methodolgy for sets

Dan

What you are looking for is a 'two-phase commit' model.

The default Access or Alpha model doesn't use that technique.

It usually consists of a statement that starts a transaction, does the steps of the transaction, then finishes with a transaction end statement. Then and only then is the data viewable by any other users. That includes the current user opening the same data in another session.

I haven't tried that model with Alpha 5 on a database that supports the 'two-phase commit' and whether you can start a transaction and later finish it or abandon it. Perhaps someone else has and can comment.

So you can try that or try one of these other options.
1. variables - as listed previously
2. assign a transaction id to each of the components of the transaction and build your own two-phase commit. Either save the components or roll back through the tables and remove the components with the given transaction id.

Personally I'd try the database that supports it first.

[MikeC]

Re: Canceling methodolgy for sets

Hi,
am wondering why a blob variable hasn't been considered using <tbl>.record_data_get() and <tbl>.record_data_set(). I have used this very effectively in "cancelling" actions after committing. Set the records to the blob prior to making any changes, then if a user wants to cancel changes made and committed, then set the record values back to the blob value.

I have a couple of forms in which I do this---mainly when the parent record has to be committed prior to creating the child. If a user gets to this point the child can still be simply cancelled, and then the parent's value gets set back to its initial value that the blob variable holds.

Is there something that is incorrect in this procedure ?? Sure seems to work and work easily.

[DaveM]

Re: Canceling methodolgy for sets

Mike,

Maybe wrong, but I think it is similar to an array. or copying to seperate variables. and changing it back if nec.

I do have one form that calls an identicla form that rolls payments(all variables in second form). If the change is liked, the changes are made to the first form.

[MikeC]

Re: Canceling methodolgy for sets

Hi Dave,
My point I guess is using <tbl>.record_data_get() and....set() can be as simple as getting the data of the parent into a blob from the button that opens up a child form using <tbl>.record_data_get(). If once on the child form and the user wants to cancel then a simple cancel does it for the child usually (if the record is not saved of course). Then if the parent also is wanted to be cancelled, then simply have the <tbl>.record_data_set() on a cancel button for the parent.

Two steps and, depending on how the forms are set up, possibly only two lines of script. Sure sounds like less overhead/maintenance than the other ways.

[Tom Cone Jr]

Re: Canceling methodolgy for sets

MIkeC, I'd be interested in seeing a working example of this. Always ready to learn something new! Thanks. -- tom

[MikeC]

Re: Canceling methodolgy for sets

Sure thing Tom--I made it slightly more involved than what I mentioned in the post but still a very easy way to "cancel" commited changes. A text box on the form should explain things. I used mostly Action Script where I could easily so that most here should be able to use this.

[CALocklin]

Re: Canceling methodolgy for sets

Hi Dave,
My point I guess is using <tbl>.record_data_get() and....set() can be as simple as getting the data of the parent into a blob from the button that opens up a child form using <tbl>.record_data_get(). If once on the child form and the user wants to cancel then a simple cancel does it for the child usually (if the record is not saved of course). Then if the parent also is wanted to be cancelled, then simply have the <tbl>.record_data_set() on a cancel button for the parent.

Two steps and, depending on how the forms are set up, possibly only two lines of script. Sure sounds like less overhead/maintenance than the other ways.

Sounds to me like this would work BUT what if the parent record did not exist and then you wanted to cancel it after starting the first child record? In this case, I think the only option would be to delete the parent record. (i.e., IF blob is empty and record canceled, THEN delete the record rather than resetting to the original blob values.)

As for autoincrementing if using temporary tables or variables, I think that could be handled fairly easily. First, use any linking value in the temp tables. Then, since the results would have to be added to the "real" tables via xbasic, first save the parent table and get the autoincremented value after saving the record, then just add that autoincremented value into the appropriate field of the child tables as each child record is created.

[MikeC]

Re: Canceling methodolgy for sets

Cal,
In the forms that I use this method, I have a few error traps that go along with what you are saying as well as a CanSave script that prevents the saving of a "blank" record--so with this in place (or a delete script as you mentioned and I have a couple of those as well in other places), even if the blob="" and this resulted in basically a blank record it simply would not be saved.

You do bring up some very valid points---as with most solutions/ways of doing things, there are going to be various error traps that will be necessary especially if there will be more than one user.

[CALocklin]

Re: Canceling methodolgy for sets

Cal,
In the forms that I use this method, I have a few error traps that go along with what you are saying as well as a CanSave script that prevents the saving of a "blank" record--so with this in place (or a delete script as you mentioned and I have a couple of those as well in other places), even if the blob="" and this resulted in basically a blank record it simply would not be saved.

Think "Enter totally new record - including parent" vs. "Change existing record." Unless I'm misunderstanding something, I believe you would have to save the parent record initially in order to start the child record. If the user then decided to cancel the whole thing, the parent record would have to be deleted because it didn't even exist initially. I doubt it would be acceptable to just leave it blank.

[MikeC]

Re: Canceling methodolgy for sets

Yep Cal,

That scenario is exactly where I have a delete operation in place.

The best way the Blob works is when a parent record is edited and commited and then a child record is brought up and the user wants to cancel everything. The child changes usually do not have to be saved and so these changes can just be cancelled. Once back on the parent form the blob can be used to cancel the changes made.

I find that the latter is most prevalent and the blob deals with it easily.

The other case in which a new parent is created as you referred to needs to have a delete operation--again fairly easy to incorporate.

I think here is another aspect of Alpha that should be placed in a FAQ or Newbie forum as am sure it is a question that will keep coming up time and again.