Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

I have written an EPOS system, in V

Status
Not open for further replies.

webpager

Programmer
Joined
Mar 27, 2001
Messages
166
Location
GB
I have written an EPOS system, in VFP (WIN98), for use in 2 retail shops.
The computers running the apps. are occasionally freezing whilst writing to the sales table.
Both machines are running with 32Mb of ram and although a little on the low side, is enough to run other programs with no problems.
We have had a total of 4 seperate computers running the program and the fault occurred on all of them.
I was wondering if anyone could suggest possible causes for the freezing. No error messages are generated and the error occurs during a 'REPLACE' 'WITH' command.
Other software (Microsoft Office etc.) runs with no problems.
 
Version is VFP6
The section where the error happens is printed below
wait window "1" nowait
Replace daysales.date with date()
wait window "2" nowait
Replace daysales.time with time()
wait window "3" nowait
Replace daysales.sale_num with new_snum
wait window "4" nowait
Replace daysales.code with new_code
wait window "5" nowait
Replace daysales.qty with new_qty
wait window "6" nowait
The wait windows are of course to test how far through the list we are when a freeze happens. The number left on the screen can be anything from 1 to 5 so I am certain it isn't a syntax problem but something a bit harder to work out.
Cheers
Keith
 
Have you tried to re-index your table? check for data corruption.

Also, when you replace with, this happens when you 'append' a new records, or modifying an exisiting record?

Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan
 
Hi webpager,

Replace daysales.date with date(), ;
daysales.time with time(), ;
daysales.sale_num with new_snum, ;
daysales.code with new_code, ;
daysales.qty with new_qty
Will be much faster than one by one replacement.


Better still will be.. if you have all these in MEMVAR and then insert in one dump.. as given below..

m.date = DATE()
m.time = time()
m.sale_num = new_sum
m.code = new_code
m.qty = new_qty
INSERT INTO daySales FROM MEMVAR
** assuming there are no other fields..

The freezing could be because of some index corruption, a bad NIC or virus slowing down the computer.

Of late, I noticed some viruses increaing the CPU activity thus freezing the system, when a network communication is taking place, while local activities seem to work normal.

:-)

____________________________________________
ramani - (Subramanian.G) :-)
When you ask VFP questions, please add VFP version.
 
Thanks guys
I used memvars but this seems to increase the number of freezes. Possibly because the machine is low on memory and assigning memvars is just adding to the useage.
How should table buffering affect the operation in this situation?
After a freeze the table is sometimes corrupted but not always. The app throws an error when the table is corrupted but reindexing the table sorts that out.

Keith
 
Webpager,

Is it possible for you to run the app for a while on a machine with more memory? At least that would eliminate one possible cause.

That said, 32 MB should be OK for VFP 6.0. I have certainly run 6.0 apps in 32 MB without the symptoms you are seeing.

You might also try installing the last service pack for VFP 6.0 (this is still available on the Microsoft site).

Mike


Mike Lewis
Edinburgh, Scotland
 
Had a bit of a test session.
Disabled Norton Anti Virus and it hasn't froze - could there be a link?
 
In the past I have also had trouble with Anti-Viruses. Particularly with VFP 5.
We are noe on VFP 7 and no problems yet.

 
Things have now taken a turn for the worst.
This program has been running for over 12 months with no problems but has now developed a very confusing error on
the second machine. I have done a full virus check and nothing is apparent
A description of program operation may help one of you clever chaps to diagnose the problem.

Till Program

Enter an item code
seek the code in the stock table
if found add it to the till roll
else
stay in the code box

...... add subsequent items to till roll

Process sale by pressing F2 - (ON KEY LABEL - do a confirmation screen)
select CASH, CHEQUE, CARD or CANCEL
enter amount tendered
till opens, via receipt printer
....... next customer

(Hope that is of some use)

The first time, the sale processes with no problem.
The next sale just freezes during the following code (a repeat of the previous code)

CASE THIS.VALUE="STOCK"
.............
OTHERWISE
If Len(alltrim(this.value))>0
OK=1
Select ASTOCK
**** Freezes at this point

Endif
ENDCASE

There are no errors reported during the BUILD process, just a system freeze, the second time the same code is run.
The table has not been closed and no code changes have been made since the program was working OK.
Is it possible something within the program is corrupted without it showing up as an error.

Please help guys - It is near Christmas and the till needs to be working.
Merry Christmas to all of you
Keith
 
Make sure you don't have any data and/or disk corruption. There is a high probability of it after any ungraceful exit from an app.
Find and delete any temp files, do a scandisk and defrag.
Rebuild all your indexes from scratch - don't just reindex.
Make sure you have sufficient file space in the data directory.


-Dave S.-
[cheers]
Even more Fox stuff at:
 
Thanks for the tips.
I have already done most of the things you mention except building the indexes from scratch. Is there a quicker way to do that, other than deleting the CDX file and selecting the indexed items from within the table modify section?

What effect do deleted records have on overall performance?
I removed a large numnber of deleted records by doing a pack, did a re-index and the program has worked fine ever since.

Should my tables be packed each time the program runs?
This is information the manuals never get round to telling us.
Many thanks
Keith
 
...Is there a quicker way to do that?
Yes, there is a quicker way. You can do it from the command line, by doing a display status and recreating them from what you see on the screen

INDEX ON SomeField1 TAG SomeTag1
INDEX ON SomeField2 + SomeField3 TAG SomeTag3
And so on.

But the best way is programmatically:
ReBuild your CDX index files
faq184-1033

What effect do deleted records have on overall performance?
Generally speaking, when you have active indexes, deleted records don't usually make too big of a difference. The best thing to do is also create an index on DELETED() so VFP can self-optimize any lookups or queries.
But, the larger the tables, the slower they will inherently be. So it is good practice to PACK once in a while.

Should my tables be packed each time the program runs?
That shouldn't really be necessary. You really won't have corruption on standalone terminal unless the app isn't shut down properly, whether it be from impatient users or power failure, or whatever.
But, if that does occur, assume there is corruption and be on the safe side.

Side note: You can add a little routine to your app that creates a flag file on startup and erases it on shutdown. If that flag file happens to already be there on startup, you can tell programmatically and force a reindex.


-Dave S.-
[cheers]
Even more Fox stuff at:
 
Dave,

The best thing to do is also create an index on DELETED()

Not necessarily. It depends on various factors, including the "sparseness" of the deleted records (the ratio of deleted records to all records). Christof Lange wrote a detailed article on the subject in Foxpro Advisor, and found that in many cases, an index on DELETED() is counter-productive.

Mike


Mike Lewis
Edinburgh, Scotland
 
I remember reading the article, but it's been a while and I've forgotten the details. But, as always, to every rule (or idea) there is an exception.
Of course, no matter what the key or tag, it always depends on the individual circumstances, but I have had good luck/results with using a 'deleted' tag. Probably because the tables I have used have had a fair amount of deleted records. In some cases, up to 1/3 of the table. These records, as a result of daily processing, get archived offline, and then recycled. So looking for a deleted record and reusing it needed to be optimized.


-Dave S.-
[cheers]
Even more Fox stuff at:
 
Dave,

I've forgotten the details of the article as well. It was just the main idea that stuck in my mind.

Of course, you were right to draw WebPager's attention to the idea of a tag on DELETED(). At the very least, it's worth experimenting with.

Mike


Mike Lewis
Edinburgh, Scotland
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top