At 11:06 2013-07-19, Ken Dibble <[email protected]> wrote:
[snip]
I went with this approach because with earlier systems, users were
somehow able to badly corrupt the data while attempting to make data
entry changes at the same time that reports involving that data were
printing. I used the same approach for report data that I do now: a
separate denormalized report-specific cursor. I've NEVER, EVER
simply done a report on a live data table. So I don't even
understand how those users were able to corrupt the live data by
editing it while a separate report cursor containing it was being
printed, but corrupt it they did, so... I went with the separate printing .exe.
I expect it was because your "cursor" was actually a
filter. If the structure of the cursor is the same as that of the
table, VFP will use a filter on the table instead of creating a
cursor. To force the cursor to be creeted, use the nofilter option as in
select * from thetable into cursor realcursor nofilter
If I go with the DO WHILE TRY...CATCH loop for ERASE, any thoughts
on how I can minimize getting into an infinite loop? Sure, I can
limit the number of iterations, but I have no idea what that limit
needs to be to be effective. Unfortunately, I can't reproduce this
problem on demand.
This has the earmarks of a race condition.
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
