Peculiar problem accessing data in DBF

[dmusicant]

As I noted in a thread yesterday, I have just acquired a PC and have been setting it up with VFP 9.0 SP2. Mostly things are working but I'm encountering a head scratching problem:

My home PCs access data stored on my NAS. This particular PC I just set up, a laptop running Vista Business, won't have internet access or a network where it's going to be deployed. I have copied the network DBFs to the laptop where the app will run against that local data. This seems to be working alright but for one table, which has 6 records presently, when I go into the table's MEMO field for any record, the second I hit my down arrow or pagedown to scroll into the information, I find myself looking at the MEMO field for the first record in the table. There are no deleted records. Thinking it might be a data corruption issue with the version of the table on the local machine, I copied the networked version back to the local machine, but the strange behavior continues. I just opened the table exclusively, packed it, the behavior continues. Any record's MEMO field shows up but the second I try to navigate within it I'm on the first record's memo field. What could be at play here? Suggestions/info appreciated.

 

[dmusicant]

I open VFP 9 on the Vista Business machine I'm having trouble with and navigate to the folder on the server where my other machines have no trouble accessing, changing and navigating browses of the Foxpro tables. Again, I have no navigation of memo editing window.

In the command window I open a table. I execute Skip 60. I execute Browse. I double click Memo. I'm looking at that record's memo field. Pressing an arrow key I find myself looking at the memo field of the first record in the table. This happens for other tables as well.

 

[dmusicant]

I already mentioned some twice, and now For the third time: %PROGRAMDATA%.

Simply open up windows explorer and copy %PROGRAMDATA% including the % signs into the address bar. press ENTER

You'll get into the system folder for public program data in C:\ProgramData."
- - - -
Yep. Well, I did this, copied one folder of the Foxpro data there and browsing the table I get similar results. I'm not always moved to the first record. Sometimes a different record, apparently earlier in the table, but always a different record the instant I press an arrow key.

The folder is C:\PROGRAMDATA\DAN MUSICANT\FOXDATA\ANS

I don't think it matters where the fox data is, this behavior is happening for any fox table anywhere, evidently.

 

[Dan Freeman]

Got a pregnant question: how is the Read-Only bit set on those files before you copy them?

If they're read-only at the operating system, they'll always be read-only to you no matter where you put them.

We used to see this a lot when people copied samples from a CD. (Files are always read-only on a CD. It's what the R in CD-ROM means. When you copy them they're still read-only.)

 

[Olaf Doschke]

Does the title of the title of the memo editing window end in [Read Only]?

Dan Freeman is right about the readonly flag, but if you also have problems with DBFs, which are unproblematic on other PCs. The only other thing s your foxuser.dbf may have the default USE option NOUPDATE for this table.

Actually I can write into DBFs and text files i create in C:\Data\, the attribute display of Windows Explorer still says read only applies to files within the folder, but each file in the folder is not readonly.

I can assure you VFP9 works on Vista, Win7 and Win8/8.1, I used it on all these OSes, there is no general problem with VFP9. Indeed I even have it installed into C:\Program Files (x86) on my Win8.1 business notebook and unless you don't want to write a config.fpw into HOME() you also have no problems with the nature of the system program files folder, even though some writes are really redirected. If you're the only user that won't matter, as file redirection will always be to your user profile Virtual Store in both writing and reading direction. As Mike said earlier on you can put a config.fpw anywhere and make a link with -C parameter pointing to the file.

Maybe your DBFs have a problem, even though they don't show the behaviour on other PCs. There must be something we don't know yet.
NTFS file system also copies security, you might have a user SID connected to your DBFs not existing on your Vista machine, like shown here:

http://cdn5.howtogeek.com/wp-conten...xUnknown-SID.png.pagespeed.ic.tjaEbrWUw9.webp

Bye, Olaf.

 

[dmusicant]

Dan Freeman:

I didn't copy from CD, I copied from my server and all files are Read/Write enabled there.

 

[dmusicant]

Olaf. I downloaded this linked in your last post:

http://cdn5.howtogeek.com/wp-content/uploads/2011/...

However, I can't open it. It's shown as .webp file. Either my PC's registry file association is wrong or I don't have a program to open it. I'm reluctant to download just anything in an attempt to open the file such as is offered here:

Link
- - - -

My thoughts if I can't figure anything else out are to try the following:

1. Uninstall VFP 9.0 on the problem Vista Business PC
2. Reinstall VFP 9.0 plus SP2 (nothing else, not bother with Sedna, etc.), this time in my own programs folder, C:\Programs3. If I'm still having the problem, install VFP 7.0. I presume I can still get updates from Microsoft for VFP 7.0 ???

I also have VFP 6, 5, 3 and FPW 2.6a

 

[dmusicant]

Interesting, I think, is the fact that this problem didn't exist at first, but only after working some with the machine after setting things up. I'm wondering if some registry setting is wrong, got set wrong somehow. I presume (hope) that uninstalling VFP 9.0 from the machine will remove all the registry settings, and a reinstall (where ever it goes) won't exhibit the problem.

 

[dmusicant]

Olaf said: The only other thing s your foxuser.dbf may have the default USE option NOUPDATE for this table.

One of the first things I tried was removing the foxuser.dbf, moving it to a new location so that a new foxuser.dbf would be generated. That didn't resolve the problem. I can't imagine that a new foxuser.dbf would generate NOUPDATE for those tables. Why would it?

 

[Olaf Doschke]

That link should just be a picture showing the case of a file security permissions tab listing an unknown user.

>The only other thing
don't take that too literal, and don't tkae it out of the context. I said that with some preconditions:
It only applies, if your memo field editing window title ends in [Read Only] and the file attribute is NOT read only. Because the only reason VFP will show this memo as read only , if the file isn't read only is, that you open the table with NOUPDATE. And that again only, if you talk of the table. There are other ways to load data into a readonly cursor, for example.

But this was under the precondition you have [Read Only] in the title bar. If the title doesn't show [Read Only] your problem can be any file corruption I never come across.

Bye, Olaf.

 

[dmusicant]

The title does not say Read Only.

Suddenly things have changed. I've set default to where I was having the same problems yesterday:

C:\PROGRAMDATA\DAN MUSICANT\FOXDATA\ANS

I opened a table, skipped 60, browsed, entered a memo field by double clicking "Memo." I pressed the down arrow and was instead looking at the memo for a previous record, however it still said at the bottom Record: 61/326.

I then did something different. I went through those steps but instead of BROWSE I ussed Modify Memo info in the command window. I found that I could navigate in the memo field without going to a different record's memo. I edited the memo field by adding a few characters and saved (Control + W). I again tried the other way using BROWSE and then entering the memo field and again the strange behavior. However, after going through these things again, now suddenly, the strange behavior has stopped! I tried a different table in the directory and things seem normal. Sigh.

I just tried running my application that accesses DBFs. The first table I opened, the first memo field I looked at seemed normal. I tried again and the strange behavior returned. "Intermittent problem," suddenly.

Now an interesting thing, I think, is that once redirected (right word?) to a different record's memo field by pressing an arrow key, I CAN edit that memo field. That field is NOT read only. Sigh.

 

[dmusicant]

I use my app to open a table, in the browse window I navigate to a random record, it says at the bottom Record: 877/964. I press an arrow key and I'm looking at a different record's memo field. At the bottom it still says Record 877/964. I press the down arrow 3 times and the blinking cursor goes three lines down. I press the letter "d" and d appears and immediately at the bottom the display changes to Record 863/964. Whatever I've written into that field gets saved when I press Control + W. The behavior is right now sporadic. Sometimes I enter a memo field and behavior seems normal. Other records' memo field, again strange.

I'd like very much to get to the bottom of this and determine what's wrong. However, at a certain point I think I should just try to work around a problem that remains unsolved and just reinstall VFP 9 after removing it, probably in other than Windows preferred location and if that doesn't work, try installing VFP 7.0 instead. If the problems persist, I can give up on running Foxpro on the machine and put it into service where one of my other laptops sits. That laptop is in a mini-dock and I don't have one for the problem machine, but I may need to do that. I think odds are good that a different install of FoxPro will not have the problem, however.

 

[dmusicant]

Olaf said:

If the title doesn't show [Read Only] your problem can be any file corruption I never come across.

I don't see Read Only. The question now, I suppose, is this caused by file corruption? My other machines aren't doing this with the same data. However, I suppose that's no proof that file corruption is not at the bottom of this.

I figured VFP came with some sample tables that presumably aren't corrupted. I found one, no problems with memo fields. However, I tried another:

C:\Program Files (X86)\Microsoft Visual Foxpro 9\Samples\Solution\solution.dbf

I'm having similar crazy behavior in its memo field, descript. Press arrow key when in the memo editing window of a record well into the table and I'm suddenly looking at the memo field of the first record, which is empty. I can then write to that memo field. So, I assume this problem does not have to do with corrupt tables.

 

[dmusicant]

Nothing has so far solved this, so I'm going to do this:

I'm uninstalling all VFP 9.0 stuff, in this order:

Hotfix KB955370
Sedna
OLE DB Provider
VFP 9.0 Pro itself

Then I will install VFP 9.0 and then SP2, I guess the Hotfix, get my config.fpw and path setting and initial program launching PRG into the HOME() directory, turn off the Task Pane Manager from launching at startup and see how things are working. If that doesn't solve things I'll install VFP 7.

 

[dmusicant]

I removed everything except VFP 9.0, electing to restore it to its original condition but the problem persists. I'm removing VFP 9.0 entirely right now.

 

[dmusicant]

I installed VFP 9 freshly in C:\Programs\VFP and the problem continues, at least for some tables.

 

[dmusicant]

I installed VFP 7.0. The link within the installation routine to check for service packs failed to find the page. Has Microsoft taken down support for it?? Well, I have VFP 7.0 SP1 saved from over 10 years ago, so I installed from that.

I don't see the problem using VFP 7.0 so far. Unfortunately, VFP 7.0 appears to lack support for display of memo field content when passing the mouse cursor over the Memo for a field, a nice feature. However, more important is being able to go into a memo field, see the whole thing and edit it! Sigh.

 

[Olaf Doschke]

>VFP 7.0 appears to lack support for display of memo field content when passing the mouse cursor over the Memo for a field
Yes, that is new in VFP9.

You didn't try to scroll in that tool tip window, did you?

Bye, Olaf.

 

[dmusicant]

I tried scrolling in the tool tip window, because you hinted that it was possible. I tried that yesterday. It wasn't working for me. I never noticed that working before. In fact, IIRC, the tool tip window expands to accommodate the size of the contents of the record's memo field, at least up to a point. I have some memo fields with a great deal of content on occasion. I have a field in most of the tables of this one app I have that is called PAGES. It is a numeric field and is calculated like this: REPLACE pages WITH LEN(ALLT((EVAL(EVAL('TheField')))))/3000

Here TheField is a variable whose value is the name of the memo field. So, I figure that the number of "pages" corresponding to the content of a memo field is approximately 1/3000th the number of characters. Seeing the value in the Pages numerical field gives me an approximation of the size of the contents of the memo field without getting tool tip view or actually going into the memo editing window.

 

[Olaf Doschke]

>I tried scrolling in the tool tip window, because you hinted that it was possible.
where?
You can only in the memo editing window. The tooltip has no scrollbar, that clearly indicates it's not scrollable.
I was just asking because that of course would also explain the behaviour you see, you'd still scroll in the main browse window and move to other records.

Indeed I would like to see a screen recording of what you actually do, maybe that would give the hint, what's wrong.
Remember you have a new computer and mouse and scroll wheel can behave differently than you are used to.

Bye, Olaf.

 

[Olaf Doschke]

Just one more question: Did you ever made new copies of the table you work on?

I ask because today someone posted back a solution of his problem with moved data and it turned out copying during live usage of the data was the culprit. If you copy file tuples or triples like dbf/cdx or dbf/fpt/cdx or also dbc/dct/dcx you can get out of sync copies, as there are live changes often changing two or all three files and if that happens, after one was already copied you can get pointers into nowhere in the copies.

The OS allows copying, but the result copies may not be consistent.

Bye, Olaf.