Foxpro Cursors: Microsoft Visual Foxpro 9.2

by: pcelbaPosted on 2009-04-16 at 13:37:52ID: 24162327

Issue

? SYS(2023)

in Command window.

It is in user's temp folder obviously but it can be changed by setting in CONFIG.FPW.

by: fmoore0001Posted on 2009-04-16 at 13:47:53ID: 24162416

Does this included the buffered cursors where you need to be able to reverse transactions?

by: pcelbaPosted on 2009-04-16 at 14:06:15ID: 24162610

Yes, temporary cursors are buffered at their location (better said cursors are in temp folder and buffering is obviously done in memory). Same rule is valid for buffered tables.

Cursor buffering is not so obvious because the cursor itself is a temporary data storage and it is used exclusively.

by: CaptainCyrilPosted on 2009-04-17 at 01:47:39ID: 24165824

Cursors are temporary tables and if they are small they reside only in memory and if they get too big they will be saved exclusively in the user's temp folder. You can change that in config.fpw. Make sure that the temp folder is located on the fastest access media.

by: Olaf_DoschkePosted on 2009-04-17 at 01:50:54ID: 24165836

If you don't specify, foxpro uses the temp file of the users account. you can specify where it should be in a config.fpw. And you should put temp files where foxpro runtime dlls are executed (!) not necessarily where runtime files are located. Eg it's bad for terminal server if temp files will be stored on client computers, that would mean network storage of cursors from the viewpoint of the process running on the terminal server.

Bye, Olaf.

by: Olaf_DoschkePosted on 2009-04-17 at 01:52:32ID: 24165840

other and simler reasons for slowness are of course missing or inappropriate indexes, wrong or insufficient use use of indexes and rushmore optimisation. Bye, Olaf.

by: CaptainCyrilPosted on 2009-04-17 at 01:56:34ID: 24165858

Even in saving FoxPro uses an index. To be sure always REINDEX or better yet recreate the index from time to time. I have that programmed at 4AM to index old FPW26 tables.

This is how:

USE table EXCLUSIVE
DELETE TAG ALL
INDEX ON field1 TAG field1
INDEX ON field2 TAG field2
USE

and so on ...

Not only this will make sure all the keys are in, but will fix any corrupted index headers. This is one of the two weaknesses of using DBF files.

by: fmoore0001Posted on 2009-04-17 at 11:48:49ID: 24170784

CaptainCyril,

The reindexing routine is a good idea, but I fear to do it on my client's network. The Write Delays he has been having can WIPE OUT tables.

by: Olaf_DoschkePosted on 2009-04-18 at 00:37:01ID: 24174288

If you DELETE TAG ALL and execute a sequence of appropirate INDEX, you will always be able to build a new CDX.
Also deep in the night there should not be the same amount of traffic that could get in your way while reindexing that way. Take a look at SYS(3050) to make less frequent network access during the reindex and do reindex in big chunks of the file or even the whole file at once.

DELETE TAGS ALL and doing several INDEX ON commands also is safer, as even if it crashes you can repeat that, while REINDEX does noeed an intact CDX to read the index key expressions from there. So that is safer regarding that aspect.

But missing row in indexes don't lead to slowness. It's rather indexes missing for where clause expressions used or vice versa using where clause expressions not having a mtching index expression. Tidying up where clauses for example, often enough the seemingly complex expressions used there were optimisable, while the tidy version is not, especially if you have compound index expressions.

Eg an index on DTOS(datefield)+charfield can be use in a where clause where DTOS(datefield)+charfield = DTOS(Date)+charvalue. And if you tidy that to WHERE datefield = DATE() and charfield = charvalue it's not rushmore optimised anymore. I've seen people doing that, being proud of clearing out "that crappy SQL", but all they did was not knowing and understanding rushmore, slowing down that SQL.

See chapters on rushmore and SYS(3054).

Bye, Olaf.

by: pcelbaPosted on 2009-04-18 at 03:45:21ID: 24174730

I would say there is another problem than indexes if the slowness is observed just on one client network whereas on other networks everything works perfectly.

This seems to be hardware problem and it should be investigated in a stress test on some temporary tables which can even be wiped out during the reindex crash. The stress test should simulate heavy network traffic stronger than obvious network loading and errors which will appear should point to possible hardware problems.

by: CaptainCyrilPosted on 2009-04-18 at 06:44:58ID: 24175239

What I suggest is running the Reindex Procedure right on the server and not on the network. It's not wise to run it across the network anyway. You can only install the reindex procedure on the server if you don't wish to install the whole app.

by: pcelbaPosted on 2009-04-18 at 06:50:56ID: 24175255

Good point Captain. This should go around the problematic network but the possibility of invalid HDD or its cable still exists.

by: CaptainCyrilPosted on 2009-04-18 at 07:27:20ID: 24175400

Yes, pcelba. We can't help if it's HDD or cable fault.

I have an app with over 2 GB of data. It takes 40 minutes to index from a workstation while it takes a few minutes on the server.

Question

Foxpro Cursors

Subscribe now for full access to Experts Exchange and get

Instant Access to this Solution

Microsoft Visual Foxpro 9.2

FoxPro Database

Trusted by hundreds of thousands everyday for fast, accurate and reliable tech support.

See what Experts Exchange can do for you.

Got a question?

We've got the answer.

Need individual assistance?

Our experts are ready to help.

Want to learn from the best?

Read articles from industry experts.

Working on a long term project?

Store your work and research.

What Makes Experts Exchange Unique?

Trusted by the world's most respected brands.

Faithfully serving IT professionals since 1996.

Related Solutions

Free Tech Articles

Cloud Class Webinars

Join the Community

Give a Little. Get a Lot.

Answers

3 Ways to Join

The Experts

The Experts

Testimonials

Testimonials

Testimonials

Business Clients

Business Clients

In the Press

In the Press

In the Press