dBase 5 for dos - Wrong dates for file last modified 3

[mikehenderson]

I am running dbase 5 for dos on windows NT v 4.1. The file date last modified usually does not get updated if clients are using dbase files located on a remote server. I say usually because every now and then or if an exclusive operation like pack is used by a client, the date and time stamps do get updated. If a user is working at the server, the date and time seem to get updated correctly most of the time.
Has anyone seen this and do you have any suggestions?

 

[MiggyD]

Sorry, I don't understand your question.

If a file is LOOKED AT ONLY then the actual SIZE is not changed therefore the MODIFIED DATE shouldn't change.

If a file is PACKED/EDITED/APPENDED/DELETED/ETC.... then the SIZE is changed therefore MODIFIED DATE should reflect the date of the last operation performed.

Does this answer help you in any way??

 

[MiggyD]

PS--If you have Word 9x on your NT. check out those files. Open a Doc, add the letter "A" to the beginning of the DOC, close it, check out the file properties and you'll see what I'm trying to say. then change the date on the system, open that DOC and remove the "A" you just put in, close it, change the date to the correct date, and again check the file's properties.

--MiggyD

 

[mikehenderson]

The file is not just looked at. It is added to or records changed and yet the date is not updated. I have confimed this by opening and seeing new or changed records and yet the date last modified has not changed. As previously noted, exclusive use of a file for packs reindexes etc works fine. The problem occurs when clients access the databases on the server as shared rather than exclusive users. This problem does not occur with any other DOS window based programs I have used. I have openede, changed and closed files on the server from client workstations in the DOS editor and other applications and the date modified changes appropriately.
Hope this clarifies my problem.
Mike

 

[MiggyD]

That is perplexing.

If you access the data through DOS programs then the date is modified. However, if you access the data throught a Window's app it does not modify the date <Here, I'm presuming you have pressed the refresh key when viewing the file>.

The only other avenue I can think of is, if they are connecting through a link icon to change the icon's sensitivity to &quot;High&quot; or let them take ownership of the file in question.

Umm, when you said &quot;It is added to...&quot; you mean a whole new record is added or did you mean an existing record is just changed by replacing a byte or two?

--MiggyD

 

[mikehenderson]

When I say added to I mean records are added and the date modified does not change consistently as described above. Interestingly, these databases have assoociated index (.mdx)files. I have seen the .mdx file date modified get updated on occasion without the .dbf file date modified changing.

 

[GEMS]

Mike, I’ve stayed out of this discussion, as I’m a DBIII only man. However, something about this problem rings a bell. DBIII stores a “date file last updated” in the .dbf file header. It enters a value when the file is first created and is only amended when…
· the .dbf file is packed (with or without records marked for deletion),
· on major field content/structure amendments,
· on minor amendments on the index records (usually)
· when the rocky raccoons start to sing.
As you might guess, I’ve found the value somewhat unreliable in DBIII+ and it might not have improved in the later issues. You can find out this value from the ? Lupdate() function when the file is in use. It’s also the date shown when you display structure eg

 display structure
Structure for database: C:\dbase\test\sample.dbf
Number of data records: 100
Date of last update   : 21/12/2000

NOTE that the date DBIII holds in the header may or may not be the same as the date maintained by the Operating System as the date of last update - ie as displayed from the DOS dir function. Is this a possible source of the confusion?
Hope this helps GEMS

 

[mikehenderson]

GEMS,
Thanks for the suggestion. Lupdate() shows the correct date of last update while a DIR listing in a dos window shows the wrong date. This proves that the problem is operatind system I guess.
Mike

 

[GEMS]

Beware of impostors!
Something about this problem, especially with lupdate() being credible stirs a memory. In a very large UK company, certain operators on specific stations were losing work and on later occasions, finding it mysteriously restored. Date-stamps on the files were screwed up as well. It was a huge DBIII+ database that many on a network subscribed to or pulled data from. The data was manipulated either directly or via turnkey applications. In the end, we found the cause was no more than one extra set of the .dbf and .ndx files lurking in a “more accessible” directory. By “more accessible” I mean that the files were on the path the application(s) would search but they were not the intended target files of the search. These copies had been probably been created to test some earlier fix and hadn’t been deleted. Then, certain machines picked these files first or maybe operators used shortened calling/name commands to get those files unwittingly. I know it seems impossible and too obviously detectable, but that problem did occur and it had a lot of high powered people fooled for a long time as I recall.
Hope this helps!
GEMS