Hey Tracy - thanks for your feedback as well. OK - here's the outcome...
FYI - this is all related to a posting I did here about a month - regarding a screen that needed to update data, was implemented via a Grid - but, needed to update data that was in MS SQL. Some of you will probably remember that thread - especially since it got a bit Heated at the time. Long & short of it... The users told me that Only ONE Person would be doing the Update to this particular table - which is a Set of Rules based upon Country. As such, I went for a bit of a brute-force method. Especially since I wanted to make the changes to this particular screen as EASY to do as possible. Understand - there is a lot of pressure on me here to Perform (especially since I am a consultant) - and a Huge list of tasks was pushed to me that were originally assigned to another Developer - since she is now working on the full conversion of the system from VFP/SQL to be VB/.Net/SQL. So - they wanted her fully freed up - and thus I had to take over the support of this system. That's why I must work quickly on things - and do things the easiest way possible. So - for this Screen - since it was already designed to work w/a VFP DBF file - I did minimal changes so that it would STILL work with a DBF file. I simply pulled in the data from SQL upon going into the screen. Then, when they hit Save - I run a Method that now pushes the changes over to SQL. What I did was still let the one Method run - which commits the changes to the VFP Table - and THEN I call the Method to do the SQL Updates. So - in theory - all changes were committed to the VFP DBF before I committed them to SQL. Yet VFP was reporting the Uncommitted changes error. So - for the Heck of it - I swapped around the order of implementing those changes - 1st pushing the changes to SQL - and THEN run the Method that commits the changes to the DBF. And - sure enough - that worked. But - WHY? Well - I forgot about that when a Record is Added - that a Date reformatting is done - so proper Date type data gets pushed to SQL. As such, yeah - those Date changes were the Uncommitted changes. Anyway - all is well that ends well... :-) -K- -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Tracy Pearson Sent: Thursday, August 20, 2015 12:36 PM To: profoxt...@leafe.com Subject: RE: Table Buffering & FLUSH(ing the Toilet)! Kurt Wendt wrote on 2015-08-20: > Hey Fred - Thanks for that input. I just spoke to my Manager about > this issue - and we both agreed that I may just stop doing the Table Buffering - and that will help avoid the current problem. But, before doing so - I will try doing the TableUpdate() command. Understood about FLUSH not committing and Uncommitted record - which is Exactly what I was hoping it WOULD Do. But AssUmption on my part... > > Dave - thanks for your input as well. > > And - Peter - I'm going to try the TableUpdate() command 1st, to see > if it solves the problem - before bothering to post all the Commands that seem not to be working right. > > FYI - this particular screen was created originally using the Wizard > - and that's part of the problem. > > Will post back my results... > > -K- > Kurt, Be sure to check the results of the TableUpdate() as well. Tracy Pearson PowerChurch Software [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com 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/80838f1ca795b14ea1af48659f35166f22c...@drexch02.corp.globetax.com ** 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.
