Mark,

I have no answers, but it sure sounds "interesting"! Maybe you could supply more information, like. . .

1) What OS is this running under?

2) What do you mean by "high volume production"?. . . Lots of data through a single instance or lots of users hitting lots of data?

3) What *else* is running along with this job? Do other things regularly run, or nothing ever, or what?

4) What video resolution are you running, and what brand of adapter is doing the video?

5) Do you have any 'favourite' OTHER things running (like some enhanced Desktop or ZipMagic or *anything*)?

Can't say I've seen anyone report problems like this, BUT then who knows how much HIGH VOLUME production is really out there? Offhand I would suspect some external thing interfering and mucking things up, but who knows?!@#@!

Good luck,
Jim N


>VFP Problems
>
>I have been having serious problems with VFP being used for high volume production. I’ve outlined some of the issues below. Has anyone seen these problems at high volume? Do you have any suggestions as to workarounds or other solutions?
>
>TIA
>
>
>1 – File is in use
>
>When running for many hours having VFP as both the front and back end table, cursors created with a SQL command are occasionally not destroyed with a use command and a subsequent SQL query will result in this error message.
>
>I have tried putting in an IF USED(… USE IN… which helps sometimes, but is ignored at others.
>I have tried having the above twice in sequence.
>I have tried deliberately slowing the process with and without the above.
>
>These have helped but not eliminated this problem.
>
>
>2 – Skipped case commands
>
>When running large jobs for many hours using VFP-VFP and VFP-SQL Server 6.5, CASE statements having an either or I.E.
>CASE lcdog=”Harry” OR lcCat=”Henrietta”
>
>gets skipped.
>
>If I change this to
>CASE lcdog=”Harry”
>
>CASE lcCat=”Henrietta”
>
>it’s more reliable, but for big jobs, it still gets skipped.
>I have tried deliberately slowing the process with and without the above.
>
>These have helped but not eliminated this problem.
>
>
>3 – When running large jobs for many hours using VFP-VFP and VFP-SQL Server 6.5, =SEEK(… doesn’t find something that’s there.
>
>I haven’t found a solution as yet.
>
>
>4 – Remote views return ASCII 0’s that look like barcodes in place of ½ of the data
>
>When running large jobs for many hours using VFP-VFP and VFP-SQL Server 6.5 using remote views, the data that comes back in a cursor of eight or so fields by six rows has one row of numbers and five rows of barcodes.
>
>I have tried deliberately slowing the process.
>
>This has eliminated this problem at a cost of processing speed