RE: To flush or not to flush, that is the question
Graham, For the Params table select no Buffering and then use Rlock(). You don't want to mix the two. Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Brown (CompSYS) Sent: 07 February 2007 19:33 To: ProFox Email List Subject: RE: To flush or not to flush, that is the question Hi The code is just use optimistic ie tableupdate(.t.) The params table is one record so will stick a rlock in for good measure as well. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Crozier Sent: 07 February 2007 17:00 To: 'ProFox Email List' Subject: RE: To flush or not to flush, that is the question Ted, I omitted to add that fact. Well expanded and amplified. Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Roche Sent: 07 February 2007 16:53 To: profox@leafe.com Subject: Re: To flush or not to flush, that is the question On 2/7/07, Dave Crozier [EMAIL PROTECTED] wrote: On the Index table how are you locking the parameter (Next record Id) table? 99% of the time VFP will do this automatically for you but I prefer the Rlock()/Flock() manual method, that way I can be SURE of getting no duplicates. This is the ONLY time I ever use manual locking however. I'd amplify your statement a little: You MUST lock a record to ensure that VFP is reading the most current value from a table. In PK generation, this is essential and mandatory. In other places in the application, that's what conflict detection is for. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
Hi John Haven't had chance to look at 9 yet. My libraries are tried and tested on v8 so need to get some spare time to check with 9. btw the scenario I have is exactly as you say, a parameters table holding the next available number. Will look at autoincs thanks. I've put the flush code out there today so will see if this fixes the problem, like you say it is highly intermittent (twice in a year!) Will also post back in a little while when I've got some feedback. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Weller Sent: 06 February 2007 18:13 To: profox@leafe.com Subject: RE: To flush or not to flush, that is the question How are you generating the invoice numbers - from a table holding the next number? I had a problem like this generating primary keys using a next number table on a couple of apps. It be-devilled us for years, I couldn't find what was causing it as it seemed to be intermittent - it only went away when I upgraded and started using auto incrementing fields. Why upgrade to VFP 8, why not VFP 9? John Weller 01380 723235 07976 393631 I've got a weird problem whereby I get duplicate invoice numbers in a vfp6 native app. Does a tableupdate issue a flush at the same time? It has just duplicated today for the second time in about a year. [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
Graham, On the Index table how are you locking the parameter (Next record Id) table? 99% of the time VFP will do this automatically for you but I prefer the Rlock()/Flock() manual method, that way I can be SURE of getting no duplicates. This is the ONLY time I ever use manual locking however. Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Brown (CompSYS) Sent: 07 February 2007 14:46 To: ProFox Email List Subject: RE: To flush or not to flush, that is the question Hi John Haven't had chance to look at 9 yet. My libraries are tried and tested on v8 so need to get some spare time to check with 9. btw the scenario I have is exactly as you say, a parameters table holding the next available number. Will look at autoincs thanks. I've put the flush code out there today so will see if this fixes the problem, like you say it is highly intermittent (twice in a year!) Will also post back in a little while when I've got some feedback. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Weller Sent: 06 February 2007 18:13 To: profox@leafe.com Subject: RE: To flush or not to flush, that is the question How are you generating the invoice numbers - from a table holding the next number? I had a problem like this generating primary keys using a next number table on a couple of apps. It be-devilled us for years, I couldn't find what was causing it as it seemed to be intermittent - it only went away when I upgraded and started using auto incrementing fields. Why upgrade to VFP 8, why not VFP 9? John Weller 01380 723235 07976 393631 I've got a weird problem whereby I get duplicate invoice numbers in a vfp6 native app. Does a tableupdate issue a flush at the same time? It has just duplicated today for the second time in about a year. [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
Re: To flush or not to flush, that is the question
Graham Brown (CompSYS) wrote: btw the scenario I have is exactly as you say, a parameters table holding the next available number. I had a bit of a problem a couple of years ago with the same scenario but we had two systems accessing the parameter table. The first was our old FPD 2.6 system and the other our newer VFP7 system. It appeared that VFP was cacheing the table and could not tell that the old system had updated it, even though we were using RLOCK() then unlock etc. What I had to do to make it work was get VFP to close the table after it had got the number. It gave me a right headache with duplicate barcode numbers. :-( Peter ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
Graham, In a lighter vein, my mother always used to say on the question to flush or not to flush: If its yellow...let it mellow but if it's brown...then FLUSH it down!! BG Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Cushing Sent: 07 February 2007 16:25 To: profox@leafe.com Subject: Re: To flush or not to flush, that is the question Graham Brown (CompSYS) wrote: btw the scenario I have is exactly as you say, a parameters table holding the next available number. I had a bit of a problem a couple of years ago with the same scenario but we had two systems accessing the parameter table. The first was our old FPD 2.6 system and the other our newer VFP7 system. It appeared that VFP was cacheing the table and could not tell that the old system had updated it, even though we were using RLOCK() then unlock etc. What I had to do to make it work was get VFP to close the table after it had got the number. It gave me a right headache with duplicate barcode numbers. :-( Peter [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
Re: To flush or not to flush, that is the question
On 2/7/07, Dave Crozier [EMAIL PROTECTED] wrote: On the Index table how are you locking the parameter (Next record Id) table? 99% of the time VFP will do this automatically for you but I prefer the Rlock()/Flock() manual method, that way I can be SURE of getting no duplicates. This is the ONLY time I ever use manual locking however. I'd amplify your statement a little: You MUST lock a record to ensure that VFP is reading the most current value from a table. In PK generation, this is essential and mandatory. In other places in the application, that's what conflict detection is for. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
Ted, I omitted to add that fact. Well expanded and amplified. Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Roche Sent: 07 February 2007 16:53 To: profox@leafe.com Subject: Re: To flush or not to flush, that is the question On 2/7/07, Dave Crozier [EMAIL PROTECTED] wrote: On the Index table how are you locking the parameter (Next record Id) table? 99% of the time VFP will do this automatically for you but I prefer the Rlock()/Flock() manual method, that way I can be SURE of getting no duplicates. This is the ONLY time I ever use manual locking however. I'd amplify your statement a little: You MUST lock a record to ensure that VFP is reading the most current value from a table. In PK generation, this is essential and mandatory. In other places in the application, that's what conflict detection is for. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
Hi The code is just use optimistic ie tableupdate(.t.) The params table is one record so will stick a rlock in for good measure as well. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Crozier Sent: 07 February 2007 17:00 To: 'ProFox Email List' Subject: RE: To flush or not to flush, that is the question Ted, I omitted to add that fact. Well expanded and amplified. Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Roche Sent: 07 February 2007 16:53 To: profox@leafe.com Subject: Re: To flush or not to flush, that is the question On 2/7/07, Dave Crozier [EMAIL PROTECTED] wrote: On the Index table how are you locking the parameter (Next record Id) table? 99% of the time VFP will do this automatically for you but I prefer the Rlock()/Flock() manual method, that way I can be SURE of getting no duplicates. This is the ONLY time I ever use manual locking however. I'd amplify your statement a little: You MUST lock a record to ensure that VFP is reading the most current value from a table. In PK generation, this is essential and mandatory. In other places in the application, that's what conflict detection is for. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
lol Cheers for that, went down lovely with supper! G. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Crozier Sent: 07 February 2007 16:30 To: 'ProFox Email List' Subject: RE: To flush or not to flush, that is the question Graham, In a lighter vein, my mother always used to say on the question to flush or not to flush: If its yellow...let it mellow but if it's brown...then FLUSH it down!! BG Dave Crozier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Cushing Sent: 07 February 2007 16:25 To: profox@leafe.com Subject: Re: To flush or not to flush, that is the question Graham Brown (CompSYS) wrote: btw the scenario I have is exactly as you say, a parameters table holding the next available number. I had a bit of a problem a couple of years ago with the same scenario but we had two systems accessing the parameter table. The first was our old FPD 2.6 system and the other our newer VFP7 system. It appeared that VFP was cacheing the table and could not tell that the old system had updated it, even though we were using RLOCK() then unlock etc. What I had to do to make it work was get VFP to close the table after it had got the number. It gave me a right headache with duplicate barcode numbers. :-( Peter [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
RE: To flush or not to flush, that is the question
How are you generating the invoice numbers - from a table holding the next number? I had a problem like this generating primary keys using a next number table on a couple of apps. It be-devilled us for years, I couldn't find what was causing it as it seemed to be intermittent - it only went away when I upgraded and started using auto incrementing fields. Why upgrade to VFP 8, why not VFP 9? John Weller 01380 723235 07976 393631 I've got a weird problem whereby I get duplicate invoice numbers in a vfp6 native app. Does a tableupdate issue a flush at the same time? It has just duplicated today for the second time in about a year. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
