Help with Set DELETED ON 1

[Judi201]

Hi,

I am having a problem with deleting records. Tables in a database are opened in the DE and accessed on multiple pages of a pageframe. I SET DELETED ON in the startup program and the record is still visible. I tried putting this in other places to no avail. So obviously I don't understand what is going on. It seems to work until the program is closed and reopened. Then the record is there again. Browsing in the command window does not show it marked for deletion. Will someone please explain what I need to do to make this record not show up. I realize that I must pack to actually remove it but 'in olden days' I could SET DELETED ON and the record was not visible and reading other posts here state the same thing. So does it have something to do with the Data Environment and I am just missing the boat?

Thanks for any help.

Judi

 

[Judi201]

Hi Jim, Olaf,

After reading Jim's reply I am thinking that I am probably on the wrong track. I just looked at the buffering because it was the last thing I added to the app.

Olaf, my project is to move a DOS FP app on an old computer to 3 new computers peer-to-peer. I only discovered that my delete was not working after I added the buffering so I looked to that as the cause. I know that I must have the buffering in place. So my plan now is to go back to a backup prior to adding buffering where everything is working and add the buffering again and make sure I don't change anything else in the meantime. I don't know what else to do. I have made sure that it works as described above and does not work if I leave it on but I know that it must be a related issue and that is what I will look for.

BTW I am using VFP 6.0 and all WINXP machines. Tables are not large and processes are mostly just entering data and printing resulting reports. Any comments or suggestions appreciated.

Many thanks!
Judi

 

[Olaf Doschke]

Hi Judi,

no you're not on the wrong track. The buffering was the cause of records not being deleted in the table. But if you use buffering, you also hav to use TABLEUPDATE(), not just switch buffering on and off, that has bad side effects if you have update conflicts.

The simplest side effect being, that the conflicts are not resolved and the user who made the last change to a record won't commit his change.

Bye, Olaf.

 

[Judi201]

Olaf,

I apologize for not explaining clearly. I have been using TABLEUPDATE() all of the time. As it stands now I have a SAVE method where TABLEUPDATE() is issued and a CANCEL method for TABLEREVERT(). I use the DELETE method to check for all records matching the criteria and DELETE FOR ... then use the SAVE to confirm and do TABLEUPDATE()

For my ADD and EDIT methods everything works fine with the same setup. I can edit a record and CANCEL with changes lost or SAVE and changes are saved. Adding new customers works the same way involving 3 different tables and I do TABLEUPDATE() OR TABLEREVERT() for each table. The DELETE method works the same way but when I close the program and reload it the records show back up even tho SET DELETED is on.

Could it possibly be something in my development setup that is causing the problem because I have not gone beyond that.(No exe, etc.) Delete is the only action that does not work correctly.

I truly appreciate any suggestions.

Judi

 

[teresas]

Judi,

It seems to work until the program is closed and reopened. Then the record is there again.

That sounds like a buffering issue to me, that your deletions are not getting processed in the source table.

I use the DELETE method to check for all records matching the criteria and DELETE FOR ... then use the SAVE to confirm and do TABLEUPDATE()

How does the DELETE method get triggered? Through the user interface? Are you using a process other than the user deleting one record at a time? Can you please explain how your DELETE FOR...works?

Teresa

 

[Olaf Doschke]

Hi Judi,

have you tried to SET DELETED OFF, then SCAN through the deleted records of the table or view and do a TABLEUPDATE on these rows? That should commit the deleted records.

Bye, Olaf.

 

[Judi201]

Hi Teresa,

Can you please explain how your DELETE FOR...works?

The user moves through the file either by clicking NEXT,etc. or SEARCH. When the customer is visible on the screen , the user selects the DELETE on the editnav bar. This calls a method that uses the code:

 DELETE FOR custno = lncustno

I have stepped through in DEBUG and know it is finding numbers and executing all code. This is shown by the fact that the record is not visible as long as I am in the same session, but if I close the app and start it again, the record is back. If I set buffering off just for the DELETE process and then set it back on afterward it works fine and I can use the buffering for everything else(SAVE,Edit.etc.)

Olaf:
No, I haven't done that but I will try it.

Thanks to all

Judi

 

[teresas]

Judi,

I'm not sure why you need a FOR clause in your DELETE statement. Isn't the record pointer located on the one record you want to delete when the command is issued?

What parameters are you using in your TABLEUPDATE() command? This is from VFP 7 help (I don't have version 6):

If nRows is 0 (or .F.) and row or table buffering is enabled, only changes made to the current record in the table or cursor are committed.

After the FOR clause, the record pointer will be at the end of the table, so maybe the update is not being requested for the record you wanted to delete.

Does that help?

Teresa

 

[Judi201]

Teresa,

Something to think about, but the correct record is deleted for the current session. It just does not remain marked for deletion once the program is closed. I can suspend, set deleted off and browse the records and see them marked. I can recall them and it works fine. But the next time the program is loaded, they are not marked. If I set buffering off with

=CURSORSETPROP("Buffering",1, "customer")

process the deletes and then turn it back on with

=CURSORSETPROP("Buffering",5, "customer")

things work fine.

I used the DELETE FOR because in the other two tables there might be more than one record and I used the same statement for all three. In each case correct records are being deleted. I used 1 for the parameter for TABLEUPDATE() as the help in VFP 6.0 is identical to the quote above.

I can use it this way but am afraid something is going on that may cause other problems and I need to know about it.

It seems that no one else has a problem like this, so I know I should not have to set it off and on.

Thanks for any ideas.

Judi

 

[JimWWinter]

Judi,

I think Teresa may have hit on the key to your problem. Using the For in your Delete statement positions your cursor at the EOF(), thus your TABLEUPDATE() doesn't update anything. Try it without the FOR and see what happens.

Good luck,
Jim

 

[Judi201]

Many thanks to all.

It seem that record pointer movement must be the culprit.

What parameters are you using in your TABLEUPDATE() command?

Seems that is the one thing that makes the difference in my setup. I said earlier that I had tried that, but apparently I had made another change as well. Now if I use TABLEUPDATE(1) in every case it works.

5 Optimistic table buffering. Allows edits to all records and does not lock them until the records are written to disk with TABLEUPDATE( ). You can use TABLEREVERT( ) to undo your changes

I read Allows edits to all records to mean table buffering, but I see now that the default 0 in the TABLEUPDATE() must have overridden the setting. If what I have said is correct then I am a little closer to understanding 'buffering'. I know of no situation where table buffering would not work for me so I will leave it at that; but, should the need arise, I at least know more of the issues involved.

Again, I would appreciate confirmation of my conclusions for future readers.

I truly appreciate all of the imput.

Judi

 

[Judi201]

Hi again,
Wanted to give Teresa a star. To me she deserves it. Of course to me everyone who offers helps deserves one but I guess that would devalue the star!

 

[teresas]

Thanks for the star, Judi! Glad I could help.

Teresa