I don't have such software; I was just clarifying your need.
Good luck!
--Mike
On 9/10/2012 3:11 PM, Sytze de Boer wrote:
Yes
With facility to edit
S
On Tue, Sep 11, 2012 at 3:06 AM, MB Software Solutions, LLC
mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
On 9/10/2012 2:28 AM,
Perhaps after reading this people here will stop trying to convince
those whose opinions differ, since it ain't gonna happen.
http://www.motherjones.com/politics/2011/03/denial-science-chris-mooney
( -or- http://j.mp/UHAID6 )
Of course, those on one end of the spectrum will
Sytze - if my memory serves me correctly - I believe that Gary Jeurink
on this list had worked on something like that a while ago. Of course, I
could be wrong...
Although - I see he has not replied to this thread yet. Maybe he hasn't
check the ProFox list e-mails in a little while...
Just
I think she crashed right off the bat in her last race... not injured but no
place. I liked it when I used to log-in and she would smile.
Gary Jeurink
-Original Message-
From: Mike Copeland [mailto:m...@ggisoft.com]
Sent: Monday, September 10, 2012 4:19 PM
To: profox@leafe.com
Subject:
On a 2.6 system, I can't duplicate this when I open the table, set the order to
every tag and browse.
I've seen where this might be an error with anti-virus software confusing the
system, although I think I have the antivirus ignoring the data directory.
Anybody else see this, which
I don't know about 2.6 but I think you can recreate the error.
I encounter it when
1 I have tables and cdx's as from (say) to day
2 I now restore the dbf's only from (say) a month ago
What I do in such a situation is to delete the cdx files and re-create the
indexes
On Wed, Sep 12, 2012 at
I have an overnight job that rebuilds it every night.
This is intermittent. I would think that once it's corrupted, this error would
occur all the time afterwards, but it doesn't. It occurs a few times a day
then it seems to heal itself. Makes no sense to me.
Caching? Server?
Original Message
Subject: Re: error 114 - index does not match table, recreate index
From: Michael Madigan mmadi10...@yahoo.com
To: profoxt...@leafe.com
Date: 9/11/2012 3:40 PM
I have an overnight job that rebuilds it every night.
This is intermittent. I
As far as I can tell, caching is turned off for all users and server.
From: Mike Copeland m...@ggisoft.com
To: profox@leafe.com
Sent: Tuesday, September 11, 2012 5:12 PM
Subject: Re: error 114 - index does not match table, recreate index
Caching? Server?
Check the network. In my case it was bad cabling.
E.
From: Michael Madigan mmadi10...@yahoo.com
To: ProFox Email List profox@leafe.com
Sent: Tuesday, September 11, 2012 6:14 PM
Subject: Re: error 114 - index does not match table, recreate index
As far as I
Sounds like it could be an antivirus program problem. Shut off antivirus on
the client and see what happens. If that fixes the problem then you have to
have your antivirus program ignore the network data directory.
If it runs well locally, it should run fairly well over the network.
Thanks for that, but we have discounted that by removing the AV software,
on the server as well as workstation
S
On Wed, Sep 12, 2012 at 1:53 PM, Michael Madigan mmadi10...@yahoo.comwrote:
Sounds like it could be an antivirus program problem. Shut off antivirus
on the client and see what
Since it only takes 5 seconds locally, it can't be a index issue or an
optimization issue.
Are the temp files set to local client disk?
editwork=c:\temp
sortwork=c:\temp
progwork=c:\temp
tmpfiles=c:\temp
From: Sytze de Boer sytze.k...@gmail.com
To: profox
Yes, config.fpw points to c:\temp
They didn't to begin with (c:\) but I changed that
I installed a basic little server at my office (Win 2003)
I copied their data to it
Running with 100 Mbit cable and swith, I get 30 secs and 5 secs on
subsequent runs
Running Gigabit cable and switch, I get 7
You might try using a statement like
...where (Date=?startdate and date=?enddate)
John
-Original Message-
From: profox-boun...@leafe.com [mailto:profox-boun...@leafe.com] On Behalf
Of Sytze de Boer
Sent: Tuesday, September 11, 2012 9:09 PM
To: profox@leafe.com
Subject: Re: Speed
Yes,
On 9/11/12 6:35 PM, Sytze de Boer wrote:
Can anyone suggest a way to make this go quicker?
Not to go quicker, but to try to close in on the problem:
Just for kicks and to try to narrow down which query (if any) is the bottleneck,
split that out into 3 select statements (ditch the UNION ALL) and
On Tue, Sep 11, 2012 at 6:35 PM, Sytze de Boer sytze.k...@gmail.com wrote:
I'm losing my mind over this
At a client site, they run a report which can take 30 mins to generate,
over the network
When they run it on a local pc, it takes 5 secs
If it's 60 sec vs 5 sec, would it be an improvement
You do have an index tag on DATE in all the tables, right?
Fred
On Tue, Sep 11, 2012 at 7:08 PM, Sytze de Boer sytze.k...@gmail.com wrote:
Yes, config.fpw points to c:\temp
They didn't to begin with (c:\) but I changed that
I installed a basic little server at my office (Win 2003)
I
Fred
(Blush) NO
S
On Wed, Sep 12, 2012 at 3:17 PM, Fred Taylor fbtay...@gmail.com wrote:
You do have an index tag on DATE in all the tables, right?
Fred
On Tue, Sep 11, 2012 at 7:08 PM, Sytze de Boer sytze.k...@gmail.com
wrote:
Yes, config.fpw points to c:\temp
They didn't to begin
That will speed it up, but it shouldn't go from 5 seconds to 30 minutes without
it, should it?
From: Sytze de Boer sytze.k...@gmail.com
To: profox@leafe.com
Sent: Tuesday, September 11, 2012 11:22 PM
Subject: Re: Speed
Fred
(Blush) NO
S
On Wed, Sep 12,
On a half-million record table...if the fields are pretty large and
text-heavy...it might.
Mike
Original Message
Subject: Re: Speed
From: Michael Madigan mmadi10...@yahoo.com
To: profoxt...@leafe.com
Date: 9/11/2012 11:53 PM
That will speed it up, but it shouldn't go from 5
If it has to drag the entire wide table vs the just the tag segments over
the wire, it could.
Fred
On Tue, Sep 11, 2012 at 9:53 PM, Michael Madigan mmadi10...@yahoo.comwrote:
That will speed it up, but it shouldn't go from 5 seconds to 30 minutes
without it, should it?
Thanks to your *hint* Fred, I can state it DOES
On Wed, Sep 12, 2012 at 5:27 PM, Fred Taylor fbtay...@gmail.com wrote:
If it has to drag the entire wide table vs the just the tag segments over
the wire, it could.
Fred
On Tue, Sep 11, 2012 at 9:53 PM, Michael Madigan mmadi10...@yahoo.com
What does SYS(3054) tell you about the optimization?
Fred
On Tue, Sep 11, 2012 at 10:29 PM, Sytze de Boer sytze.k...@gmail.comwrote:
Thanks to your *hint* Fred, I can state it DOES
On Wed, Sep 12, 2012 at 5:27 PM, Fred Taylor fbtay...@gmail.com wrote:
If it has to drag the entire wide
Le 12/09/2012 04:36, John Harvey a écrit :
You might try using a statement like
...where (Date=?startdate and date=?enddate)
Going further : BETWEEN(date, start, end) is a VFP function, not a SQL clause.
You should write
WHERE date BETWEEN start AND end
The Foxil
Internally, I don't think there's a difference, it's just syntax.
Fred
On Tue, Sep 11, 2012 at 10:39 PM, Jean MAURICE jsm.maur...@wanadoo.frwrote:
Le 12/09/2012 04:36, John Harvey a écrit :
You might try using a statement like
...where (Date=?startdate and date=?enddate)
Going further
26 matches
Mail list logo
