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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

About that c0000005 error again 7

Status
Not open for further replies.

herbstgy

Programmer
Jan 30, 2018
51
0
6
HU
Greetings, Everyone...

there's an application I'm developing and when I was stuck, you guys were very helpful in the earlier cases.
so, here I am again.
currently with that good old c0000005 exception error that has been our good friend for a long time.
I've read back and forth this forum and others what to do with it but no avail.
so, here's the thing.
there's a form with a grid in it.
it looks like this:
1_qmhpdh.png

the grid is readonly from the user's side, but constantly updates from network side (it's a log reader)
the c0000005 error usually occurs at grid update, but quite randomly. sometimes it goes without it for a half day, sometimes it pops out its ugly head after half an hour.
I've been trying the following:
- patched the VFP version to the latest - it's Visual FoxPro 09.00.0000.7423
- got rid of the WITH/ENDWITH constructs
- turned SET RESOURCE OFF - it didn't solve the problem, but raised others, so I turned back on
- the tables shown in the grid have no memo fields. it consists fields from multiple relational tables, but no memo field
- the form runs in its own private data session with only opened the needed tables
- the error only appears in the compiled EXE, but never in the IDE

I have the vfp9Rerr.log, it shows multiple locations as the source of the error but they're always somewhere around the grid.



Fatal error: Exception code=C0000005 @ 2020.11.09 08:43:15. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 22 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.09 11:34:48. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.init line 65 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.09 13:05:20. Error log file: \\Auth4\auth4f\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {\\auth4\auth4f\naplo\watchman.sct \\auth4\auth4f\naplo\watchman.sct}
Called from - main line 5 {\\Auth4\auth4f\Naplo\main.prg \\auth4\auth4f\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.09 23:51:37. Error log file: N:\Naplo\VFP9Rerr.log


Fatal error: Exception code=C0000005 @ 2020.11.10 00:38:44. Error log file: N:\Naplo\VFP9Rerr.log


Fatal error: Exception code=C0000005 @ 2020.11.10 02:29:42. Error log file: N:\Naplo\VFP9Rerr.log


Fatal error: Exception code=C0000005 @ 2020.11.10 13:50:19. Error log file: N:\Naplo\VFP9Rerr.log
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.10 13:52:46. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.10 17:57:36. Error log file: N:\Naplo\VFP9Rerr.log
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.11 10:56:14. Error log file: \\Auth4\auth4f\Naplo\VFP9Rerr.log
Called from - geplist.commandgroup2.lekerwm.click line 2 {\\auth4\auth4f\naplo\geplist.sct \\auth4\auth4f\naplo\geplist.sct}
Called from - geplist.keypress line 19 {\\auth4\auth4f\naplo\geplist.sct \\auth4\auth4f\naplo\geplist.sct}
Called from - main line 5 {\\Auth4\auth4f\Naplo\main.prg \\auth4\auth4f\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.11 12:02:21. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman_main.refreshyellow line 18 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}
Called from - watchman_main.timer1.timer line 43 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.11 13:57:56. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 22 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.11 14:47:31. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.11 15:33:55. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.12 09:51:22. Error log file: N:\Naplo\VFP9Rerr.log
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.12 11:51:03. Error log file: N:\Naplo\VFP9Rerr.log
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.12 15:39:24. Error log file: \\Auth4\auth4f\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {\\auth4\auth4f\naplo\watchman.sct \\auth4\auth4f\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {\\auth4\auth4f\naplo\watchman.sct \\auth4\auth4f\naplo\watchman.sct}
Called from - main line 5 {\\Auth4\auth4f\Naplo\main.prg \\auth4\auth4f\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.13 16:18:50. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.15 07:32:01. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.16 12:40:34. Error log file: N:\Naplo\VFP9Rerr.log
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.18 11:58:55. Error log file: N:\Naplo\VFP9Rerr.log
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.19 14:13:58. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.init line 65 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.20 10:35:26. Error log file: N:\Naplo\VFP9Rerr.log
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.21 08:00:51. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 22 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.21 08:15:55. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman_main.refreshcyan line 18 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}
Called from - watchman_main.timer1.timer line 11 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.21 12:16:05. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 8 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.21 13:35:48. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.24 11:11:07. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Fatal error: Exception code=C0000005 @ 2020.11.24 12:18:26. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 8 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}


Any ideas?
 
Hi herbstgy,

I don't know your network/server topology, so therefore I might assume some wrong things...

so...for starters... why do you start your app from a fileserver? Within a network that is protected and controlled via AD, firewalls and AntiVirus your app has more than enough probs to be loaded. There is no need to place it on a networkdrive so it has to deal with network loads, old switches and network cables or bad system drivers a.s.o.

The cheapest option would be to reinstall your app on the local PCs, but without an automatismn to update your app from the network, this might raise other problems.
My favorite way of installing an app is directly on a server and access it via remote desktop (RDP). However, this needs a more expensive server license than a simple fileserver that might even be a linux server. Usually a win2016 10 user rdp server license costs ~200 Euro, so not an unattainable goal.

However, a pure VFP9Err.log analysis won't help either. You should add local logging to your app where activities with potential for errors are written into a user specific file on the local harddrive.

You can do this with

Code:
=UserLog( [calling Form #1] )

FUNCTION UserLog
LPARAMETERS pcString as String
	STRTOFILE(TTOC(DATETIME())+[ ]+pcString,ADDBS(GETENV([USERPROFILE]))+FORCEEXT(GETENV([USERNAME])+DTOC(DATE(),1),[log]),1)
ENDFUNC

As soon a a C0000005 is fired, switch to the log and search for the timestamp right before the VFP9Err.log timestamp.That way you should be able to work out the area that causes the C0000005.

Nevertheless as C00000005/6/7 errors come with driver problems for graphic cards, network, you name it, RDP should be the way to go.

JM2C

-Tom
 
Hi,

Fatal error: Exception code=C0000005 @ 2020.11.24 12:18:26. Error log file: N:\Naplo\VFP9Rerr.log
Called from - watchman.timer1.timer line 8 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - main line 5 {N:\Naplo\main.prg n:\naplo\proj1.exe}

There seems to be at least one problem with the timers and the AfterRowColChange() method in different forms e.o. watchman.sct - line 8. You may want to check their code
hth
MarK
 
Not sure this will help - but has to be worth a try


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Dear All,

@Tom,

thank you for your answer. I appreciate your good will, but your ideas unfortunately not doable for me. it's a distributed system with multiple users using it concurrently who has to see each other's posts as they post them, as well as the distributed log files which come from a mainframe.
so I have to stick with the shared database.
the exe itself COULD be installed on the workstations, but it would be PITA to update them and keep the version checking and I don't believe it would solve my problem.
Also for the RDP solution... it would take more resources both on server and client side, and I don't see how multiple users could use the same database that way. Also, I only have access to the server as file server, so I have to stick with that.

@Mark,

I checked the sources VFP9Rerr.log mentions many times, but I haven't got a solution. that mentioned line 8 only contains a mere "thisform.lockscreen=.t.", so I don't know what could be wrong with it...

@Griff

I suspected as much that the c0000005 error could have something to do with DEP. the moments before the error occurs, the app freezes for a couple of seconds, like it's scanning through the complete memory... the more memory I have, it takes longer.
Unfortunately, setting DEP on/off would take admin access, which I don't have on the workstations the program runs on.


so I guess I have to keep on hunting.
if you guys have more ideas, hit me with them. :)

p.s.
the error haven't occured in the last 24 hours. don't know why - I haven't made any major change that would explain it. I'm curious why it disappeared and when will return...

cheers
 
Hi,

... line 8 only contains a mere "thisform.lockscreen=.t.", so I don't know what could be wrong with it...

Please have a look at the explanation below (from Hacker's Guide to VFP 7 by T. Granor, T. Roche et al)

LockScreen

This property lets you make a bunch of changes to a form at once without the user seeing each change as it happens. Not only that, it speeds up the process. However, be careful because it can make it look like the system is hung.

Usage
frmForm.LockScreen = lBatchChanges
lBatchChanges = frmForm.LockScreen

Some changes aren't batched, even when LockScreen is .T. It appears that the ones that affect the form window itself, like the form's Caption, BorderStyle, MaxButton, MinButton, ControlBox, and the like, and the ones controlling the form's position, like Left and Top, happen anyway. Changes that affect the interior of the form appear to be batched.

Don't change WindowState while LockScreen is .T. The borders change, but the interior doesn't get repainted.

Setting LockScreen can speed up the process of making changes because the form is repainted only once instead of multiple times. Even if wasn't really faster, it would probably look faster because the changes "snap" into place instead of being executed one at a time. (However, we should add that we've heard a few people argue that LockScreen actually slows things down. So, as always, test in your application for definitive answers.)

OLE Controls typically are not affected by LockScreen because, even though we consider them to be "on" our forms, they are actually individual Windows windows, and they don't know from LockScreen. To make changes more quickly to some OLE Controls, turn LockScreen on for the form, then move the OLE Control to a position off-screen, say, -1000, -1000. Make the changes to the OLE Control, then put it back where it was. Set LockScreen to .F. and the form repaints. This trick can speed up the process of making a lot of changes to an OLE Control, in cases where each change normally would cause the entire control to repaint. A smart control recognizes that it is not in the visible area of the display, and doesn't bother with the relatively slow repainting.

To make your heart stop, try setting LockScreen .T. for the active form, then Alt+Tab over to another application and back to Visual FoxPro. See how the box identifying Visual FoxPro doesn't go away? [highlight #FCE94F]Imagine this happening to your user. How long would it take her to hit Ctrl+Alt+Delete? Make sure you don't leave LockScreen .T. for too long.[/highlight]

Example
ThisForm.LockScreen = .T.
ThisForm.BackColor = RGB(0,0,255)
ThisForm.Text1.Left = ThisForm.Text1.Left+10
ThisForm.SetAll("FontName", "Arial")
ThisForm.LockScreen = .F.

hth

MarK
 
Herbstgy,

Can I ask you a question? I am curious to know what is the language of the text in your grid. It looks to me like a Finno-Uric language, but I know enough Finnish to rule that out. So I'm guessing it is either Estonian or Hungarian.

Am I close?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Dear All,

@Mark,

I just lock the screen for the time I refresh the grid. It was just another failed attempt to get rid of the c0000005 error. :) should I take it out?

@Mike,

yes, it is indeed Hungarian mixed with English here and there. :)

@Tom,

yes, the dbf do have an index (on the date+time field). The table is constantly open on multiple workstations so I can't open it exclusively to reindex it. Anyway, I didn't get any errors that point to corrupted index files. when the c0000005 error occurs, the users usually just swear a little under their noses, restart the program and it runs again like nothing happened. :)
if the index would be corrupted, I guess the app would collapse on every workstation at the same time.

regards
 
Hi,

If you carefully read the log files you'll find out that there are only three forms involved and only a few methods/events. You may want to check the code they run. Below the regrouped overview

WATCHMAN.SCT

Called from - watchman.init line 65 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.timer1.timer line 22 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.afterrowcolchange line 3 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.grid1.mousemove line 7 {n:\naplo\watchman.sct n:\naplo\watchman.sct}
Called from - watchman.timer1.timer line 8 {n:\naplo\watchman.sct n:\naplo\watchman.sct}

GEPLIST.SCT

Called from - geplist.commandgroup2.lekerwm.click line 2 {n:\naplo\geplist.sct n:\naplo\geplist.sct}
Called from - geplist.keypress line 19 {n:\naplo\geplist.sct n:\naplo\geplist.sct}

WATCHMAN-MAIN.SCT

Called from - watchman_main.refreshyellow line 18 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}
Called from - watchman_main.timer1.timer line 43 {n:\naplo\watchman_main.sct n:\naplo\watchman_main.sct}

hth

MarK
 
yeah, Mark, I've been running these circles many times in the last two years. :)

basically it goes like this:
- watchman_main.scx is the main form in this case to begin with, it contains the list of ATM's that needs attention.
- the user double clicks on one of the ATM ID's, this calls geplist.scx with the details of that ATM.
- then the user clicks on the toolbar in that form or presses the appropriate button to list the last EMS messages of that ATM which calls watchman.scx
- then comes the c0000005 error in watchman.scx usually when the user tries to move in the grid or when a new message arrives in the table, and in VFP9Err.log it points back to basically random lines somewhere in the calling chain

what really causing all of this still eludes me...
 
From what you describe, all points to the DBF file. I also understand it's never corrupt, and after a restart, it still works. But did you try to add a layer here - pull records into a cursor you show in the grid instead of binding to the DBF directly? Even though the issue doesn't seem to be the usual complications with corrupt DBF files, there's something going on because of multiuser access. Decoupling it may help to get no conflict as each user will have his private cursor for the grid. You then limit the chance of conflicts to the time of querying the DBF.

I don't know how much you rely on the REFRESH setting to update the grid and don't want to lose that mechanism. You might need to query the DBF often instead, but how many records are of interest? Rather the latest records only, right? Maybe think about archiving old records into a different DBF and then recycle the records in the main DBF. In the end, once you have a contingent of say 1000 rows or something like 5 rows per ATM you don't append it but gather into the oldest record of the ATM after copying it to the archive DBF.

The archive DBF then can also contribute to the details of a single ATM. Maybe you just even make the current DBF the archive having all data and query latest records into a permanently smaller DBF from which any user then queries the watchman_main.scx list.

Any idea in the direction of decoupling users from using the same file concurrently helps to stabilize any VFP application. Plus, the problem rarely is with small DBFs, that's why it normally arises after a long time of working when something grew to a critical size.

Chriss
 
Dear Chriss,

actually, I did try the approach you mentioned to pull the records into a temporary cursor to display them. The early versions of the form was written like that. But it didn't work quite well. Sometimes - quite often - the users want to see the log refreshed in near real time (when they start a download on the ATM or when the ATM climbs back from a previous communication error) and pulling the log records into a temporary cursor would cause a lot of requerying in that case.

But you gave me an idea.
I issued a "SET REFRESH TO 0" in the form's load method, and resort only to programatic refreshes in the form's timer method, so maybe the two won't clash.
We'll see where it gets me.

For your other question, I indeed do rotate the log files. I open a new log file every month so the file size stays manageable. This way, the size of main log file stays around 800000-1000000 records by the end of the month.

cheers.
 
A little tip that may or may not be applicable in your situation. Take it or leave it :)
I have some logfiles in my applications that have the current month in their filenames.
Since I seldom have any use for logfiles older than a year, it doesn't matter that I overwrite the older files from last year.
 
herbstgy,

I wouldn't consider 800,000 to 1,000,000 records a small DBF size.

The question is whether errors happen more frequently at the end of a month. It might help to create weekly or daily DBFs. You could also use a double logging time overlapping approach. For example, create a DBF every 30 minutes, use the second oldest DBF in the grid. When you create a new DBF switch to the second oldest and archive the oldest.

At some time you start with a single DBF as usual, say at 0:00 am, 0:30 am you create a new DBF and log the same records into it than into the first file, still use the first file in the grid. Then at 1:00 am create a third DBF, stop using the 0:00 am DBF for the grid and show the 0:30 am DBF which means the grid sees the last 30 minutes and you can't scroll back to data from 0:00 am to 0:30 am, but you could allow paging back to older files.

It's needing double hard drive space, but that shouldn't be a problem. You could later delete files with the half-hour shift and only keep the full-hour DBFs.

Chriss
 
...and always log into the two latest DBFs only, of course. So at 1:00 am the DBF created at 0:00 am has its final state and no further data is logged to it.

Chriss
 
Hi,

... or create a parameterized view of the dbf e.g. WHERE DateTime() - YourDateTimeField < 3600 and make it the RECORDSOURCE of your grid

You'll only have to REQUERY() the view at the desired pace and you'll always have the updated data without having to worry about the size of the daily/monthly dbf

hth

marK
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top