vfp slowed down

[foxup]

Hi,

I was running a query and I had to end task it but now my VFp seems very very slow when running queries. Are there any temp files that get created that I can delete manually (just in case something got corrupt). How about the config.fpw file? or foxuser.* files?

Would any of those (if corrupted) slow down my queries?

what could have happened?

any help please!

thanks,
J

 

[Mike Lewis]

I can't imagine that the files you mentioned would have any effect on the speed of a query.

But there's no harm in deleting your temp files: just go to the %TEMP% folder and delete everything.

It's highly unlikely your Config.FPW has got corrupted, but you can always open it in a text editor to check. If your Foxuser files have got corrupted, my guess is that VFP won't even open them. You can always try deleting them to be on the safe side.

It's much more likely that something else is causing the slowdown. The first thing to determine is whether it was the result you having to "end task" the previous query. The easiest way to check that is to re-boot your computer. If the slowdown is still there, there must be some other reason for it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

I also see a slow down of foxpro after "heavy querying". I can only assume this is because of foxpro cashing of data. Restarting foxpro resolves that.

Bye, Olaf.

 

[foxup]

I tried a reboot and still very slow.

I checked hard disk - OK
I check for spyware - none
I check for virus- none
Did a disk clean
Did a defrag
cleaned all temp files

still slow.

I seems to be that once the queries are run. I see the query window but once type in quit it just freezes/jams for quite a long long while before quiting.

any help?????

I'm thinking of re-installing VFP but don't really want to.

please help.

thanks,
J

 

[Olaf Doschke]

So, you have a slow vfp even right after a fresh boot? Or is it always getting slow after the query again?

If it's the latter, of course, that is a reproducable slow down and there is little you can do, but to change your queries to process smaller portions of data or call SYS(1104) once in a while inbetween.

If your vfp is slow from the beginning now, I don't know, try the usual stuff, recreating resource (foxuser.dbf) and recreate intellisense data (Menu: Tools->Intellisense Manager: Advanced Tab->Clean Up), as that is running scripts while you type something.

Bye, Olaf.

 

[Olaf Doschke]

I see this sluggish vfp behaviour, after I do queries resulting in huge result sets. And while that sometimes is unavoidable, eg for migrating huge portions of data, it also sometimes is simply caused by a missing or wrong join condition, eg if you SELECT * FROM table1,table2 without giving any where condition, the result will have any combination of records from table1 and table2. This is called cartesien product and if eg both tables are rather smalle with 1000 records each, the result has 1000x1000= a million records. And that's also cached and does slow down VFP, especially if you do a series of such queries.

Bye, Olaf.

 

[Mike Lewis]

Foxup,

Could you clarify a few points:

Is it one particular query that's slow, or all queries?

Does the slowness happen all the time, or only after you run a particular query?

By "query", I assume you mean a SQL SELECT? Is that right?

You wrote: I see the query window but once type in quit it just freezes/jams for quite a long long while before quiting. What do you mean by the "query window"? And do you mean that if you type QUIT in the command window, it takes a long time for VFP to actually close down?

If you could clear up those points, it might be easier to find the solution.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[alvechurchdata]

Just to add to Mike's thoughts, are you connecting to data on a server and has anything changed on the network recently?

Geoff

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[foxup]

Queries using SELE from large DBF on local machine are slow all of a sudden. It wasnt' like that before.

I run the query. It runs OK. I see the query window popup. I browse the data. As soon as a press ESC to get out of the query so that the I can get to the "command box" it 'hangs' for a while, then after a nice little while everything is OK.

I will cleaned the intelisense hoping that will help. doesn't really seem noticable.

any other help please.

thanks,
j

 

[foxup]

yes, sorry, forgot to add, yes, it takes a long time for VFP to actually close down or to get back to the command box window.

 

[Olaf Doschke]

From what you describe it should really just be, what I know, high memory consumption of VFP can mean that a) cursors (liek "Query" are actually written to disc - which is not done, if results are small. Also RAM may be swapped to pagefile.sys and of course this causes really slo sluggish behaviour.

There's nothing you can really do. I assume your computer has 4GB or more, 2GB is the maximum VFP can allocate and work with. Otherwise there is no acceleration possible, but to limit your query results more than you do now.

If, as you implicitly say, the queries where faster previeously, check what indexes are defined. You may have deleted tags incidently or not, that of course is makeing quereis slower and not only that, they also make VFP read more of the dbf, as it needs to read the data (table scan) instead of using the index (lookups in the cdx file).

Bye, Olaf.

 

[foxup]

As mentionned, the query runs OK, but it at this point where it freezes/halts for a while

I run the query. It runs OK. I see the query window popup. I browse the data. As soon as a press ESC to get out of the query so that the I can get to the "command box" it 'hangs' for a while, then after a nice little while everything is OK or it takes a long time for VFP to actually close down after that big query.

I'm almost 100% sure it wasn't that way before.

please, any other ideas?

 

[Dan Freeman]

What you're describing sounds like the result of background fetch. VFP will display the browse window immediately with the first 25 rows returned, and will continue returning results while you work with the browse window.

The reason it doesn't release immediately is because the query is still running.

But this should only effect querying remote data. Something doesn't add up here.

In any case, reducing the size of the result set should help you. Is it *really* productive to browse huge amounts of data? Anything more than a handful of records is just unproductive, IMO.

 

[Olaf Doschke]

The only way such queries don't hog the RAM and make vfp slow down is, VFP can optimize the query with a filter. So either you dropped an index tag (you didn't answer my question in regard of indexes) or your query got more complex and so a filter isn't applicable anymore.

Like dan says, browsing huge amount of data isn't productive. The only time I have huge amounts of data in a browse is, when I open a huge table and use brwose on it, but that's a totally different story in comparison with a query, as the browse window (or the grid) is very clever about only retrieving the records needed to display.

Bye, Olaf.

 

[foxup]

OK, I'll see what I can do. Thanks.