RE: To flush or not to flush, that is the question

E: 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 Sen

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 li

RE: To flush or not to flush, that is the question

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 Subje

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

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 th

RE: To flush or not to flush, that is the question

er 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

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

RE: To flush or not to flush, that is the question

. 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 librarie

RE: To flush or not to flush, that is the question

nt: 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-

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

To flush or not to flush, that is the question

Hi all 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. I'm in the process of upgrading this one to VFP8/CAa & SQLServer so hopefully not a p