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]

OK, I just opened another of the DBF's and am getting similar strange behavior. Go into any MEMO field, press the down arrow and I find that I'm looking at the MEMO field of a different record. The record pointer at the bottom of the screen does not correspond with the record whose MEMO field I'm then looking at, e.g. Record 4/114. Closing and reopening VFP has had no effect. I'll try a reboot...

 

[dmusicant]

I deleted the new VFP 9's FOXUSER.DBF file (cut and paste in a new location), the behavior continues. I had VFP look at the NAS version of the data, still can't move within a MEMO file without immediately seeing another record's MEMO file. My other machine here has no problem with the same data. I wasn't having this problem a couple of hours ago. I don't know what to think other than totally reinstall VFP, however that's not a trivial matter with all the add-ons. And I'm not the least bit sure that will stop this peculiar behavior. Suggestions appreciated.

 

[dmusicant]

Rebooting was no help. Actually the only thing I can think of is to run both the apps here in FPW 2.6a. They really should work with that as long as the tables are all FPW compliant tables. They probably aren't, but I have written a function that will batch convert all the tables to FPW compliant tables. Good thing because there are 429 tables presently. Presumably, FPW won't have the same problem... ???

 

[dmusicant]

Of course, using FPW on the Vista Business 64bit machine may problem very problematical. Hm. Well, does anyone have any idea what the problem is?

 

[Olaf Doschke]

I never saw such a memo defect or general behaviour.
The central question is: Where did you put the dbfs?

There are several forseen places for data:
1. for shared acccess a file share on a server
2. for an application storing data local for all users: %PROGRAMDATA%/yourcompanyorpersonalname/yourapp/ (this is C:\Programdata on Win7, for example)
3. for a single user application: %LOCALAPPDATA%/yourcompanyorpersonalname/yourapp/ (this is the Appdata/Local subfolder of the user profile)

The easiest way to get these is via GetEnv() and installshield also offers system folders to specify where files are put at setup in a generic way not specifying folders hardcoded.

Today all folder names in the file system are english and locale folder names result from the desktop.ini in the system folders specifying a LocalizedResourceName.

For further info refer to

http://doughennig.com/papers/Pub/Vista.pdf

Bye, Olaf.

 

[Mike Lewis]

I'm puzzled by your statement: 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.

What do you mean by "go into a memo field"? And when you say your are "looking at the memo field", what exactly are you looking at? Are you in a memo editing window, or a browse, or an edit box, or what?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Mike and Olaf:

When you enter a memo field the cursor is initially just in front of the first character, i.e. at the top left. Any thing I do that would move the location of that cursor has me immediately seeing the same memo field for a DIFFERENT record in the table. Yes, I think "peculiar" is an apt word for it. I don't recall seeing it before using Foxpro.

When I say I'm looking at a memo field I mean this: I browse the table and either double click "Memo" or put my cursor there and hit either Ctrl+PgUp or Ctrl+PgDn. Any of these three will have you in (or "looking at") the memo field's content. With this particular machine right now, for whatever reason, once I'm in the memo field, looking at its content, I can't move the cursor from its initial position (by using the mouse or arrow keys) without being immediately transported to looking at the memo field for a different record of the table. Initially, I was dealing with a 6 record table and it was going to the first record's memo field (that particular table has just one memo field, as do most that this application uses). I experimented with some other tables and I was sent into seemingly random other records' memo fields. Well, I have every version of FoxPro from FPW 2.6a to VFP 9.0 except for 8.0, I could try another, say VFP 7.0. I am also thinking of swapping the machine with one of my other laptops, which I presume will not have this problem. I figured you guys would have the answer. I think that next I will do some HD integrity analysis, run crystaldiskinfo and/or Western Digital Data Lifeguard Diagnostics.

In terms of where I have the data, I've always chosen my own locations and never had a problem. In this case the data is in one of these locations:

C:\data\ans
C:\data\ans\sen

There are tables of metadata that tell FoxPro where to look for tables, those tables are all in:
C:\data\ans\metadata

Only a dozen or so tables are in C:\data\ans\sen, over 400 tables are in C:\data\ans.

I could experiment with other location, such as Olaf suggests. I wonder why this should be necessary. Adding to the mystery of this is the fact that I wasn't seeing this behavior earlier in the day yesterday.

My other machines look at this data on the network. This one looks at the same data locally (as long as the tables haven't been changed either locally or on the server machine). I simply copied the tables from the server to the local machine. The reason I'm doing this is that this machine will reside where it not only doesn't have access to my network, it will not have internet access. My intention is to keep its tables "current" by bringing a flash drive with the tables that have changed since the last update.

 

[dmusicant]

Mike, I suppose you would say that this happens when I try to move the cursor when I'm "in a memo editing window." I get in that window from a browse by either double clicking "Memo" or hitting either Ctrl+PgUp or Ctrl+PgDn.

 

[Mike Lewis]

Mike, I suppose you would say that this happens when I try to move the cursor when I'm "in a memo editing window." I get in that window from a browse by either double clicking "Memo" or hitting either Ctrl+PgUp or Ctrl+PgDn.

OK, that makes sense. But I hope you understand why I raised the point. A memo field is a piece of data within a table. A memo editing window is a mechanism for viewing that data. I'm not saying this to be pernickety. But rather to make the point that you'll never solve a problem if you can't describe it clearly and precisely.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I can think of a simple reason for the behaviour you see. You put your DBFs into a system folder and readonly access strikes again. If a cursor is readonly and you change to the memo edit window, your cursor movements might still just be going to the main brows window and therefore you don't move inside one memo value but between records.

In fact it's a nice thing you can position the memo window beside the browse, resize it, so you can see the full value in it, and then activate the browse and move through records.

Bye, Olaf.

 

[dmusicant]

I looked at my C:\data folder and it was Read Only. I asked the OS to make it NOT Read Only, and it did so, and for all subfolders and file. However, it did not persist. After clicking OK, the entire folder and subfolders again became Read Only. Nice, Microsoft.

Well, Olaf, it looks like your take on it isn't off base. I will move the data. Where exactly, I don't know. I will try to decipher your explanations above, I'm sure I can do that somehow. I didn't have this problem with my Win7 machines, but that's probably because the data is on D:\... ... I have an extra partition on those Win7 machine HDs.

 

[Olaf Doschke]

Just tried to create a normal C:\Data\ folder. Indeed you always get a fully filled checkbox for the readonly attribute (with the annotation it only applies to files within the folder).
That migh come from C:\being root drive. But one thing should be noted: A fully filled checkbox does not mean checked, a checked checkbox has a check icon in it. A fully filled checkbox means this attribute is partly set. And that migt be due to the desktop.ini system file.

Anyway, C:\Public is a public folder, where you can also add your app data. And what I said earlier for %PROGRAMDATA% and %LOCALAPPDATA% applies.

You might be true working on a separate partition solves some of the problems. On the system drive you better use the right system folder for your aim, there are system executable and data folders.

Bye, Olaf.

 

[dmusicant]

So far I'm having no luck in finding a place where my DBF's will not be Read Only on the HD. The PDF you link, Olaf, says:

Alternatively, you can create your own folder in the root of the drive (for example, C:\Super Happy Fun
Ball) to store application data.

However, that hasn't worked for my C:\Data folder. Everything under it is Read Only. I set the folder and subfolders/files to not Read Only, but the settings immediately revert.

 

[Olaf Doschke]

Well, I'm not Doug Hennnig, but perhaps it was true, when he wrote it. But you got alternatives from me, not all system folders are readonly, there are data folders.

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.

Here you can create a folder for your application, the recommendation is first a folder with company name (alternatively your name) and then folders for your apps.

GETENV("PROGRAMDATA") can be used in VFP to refer to that folder. The system environment variable %PROGRAMDATA% is available via GETENV just like other system variables are.
And this call will also work on XP, Vista, Win7 and Win8. It may result in different absolute paths, but all of them will work for data on these OSes.

Bye, Olaf.

 

[dmusicant]

??? Well, I copied a folder of DBFs from the server to C:\users\public (I think this is what you meant, because there is not C:\Public folder), and again trying to move the mouse cursor within a memo editing field gets me to a different record's memo field. I then set the VFP default to the server table (i.e. in its place on the server), and again have this peculiar behavior. I'm pretty confused about this. The server based versions of the files are not read only, my other machines (this one in particular) aren't doing this. This machine has Windows XP Pro.

 

[dmusicant]

Using the Vista machine, I have a table open that resides on the server. I go to a record in the table, a browse window. I can edit a character field then move to a different record and my edit persists, proving that my change has been recorded on the server. I then go back, undo my edit, go into the memo field for the record, press an arrow key (e.g. -->), and I'm immediately looking at the memo field in a different record. This different record happens to be the first one in the table. The table has 326 records. I can edit that memo field, the edit persists. If I then go back to a browse and move the record pointer to a different record and go into it's memo field and press the --> key, I'm again in the first record's memo field, and I see the edit I made a minute ago. The file is obviously not read only in any sense.

 

[Olaf Doschke]

>trying to move the mouse cursor within a memo editing field

You have to click inside the memo editing field to have the text cursor inside the memo editing window.
If you merely hover the mouse cursor over a window and use the mouse scroll wheel, you still scroll pageup/down in the main browse window.

This is not at all peculiar.

Bye, Olaf.

 

[Olaf Doschke]

Forget what I said about scroll wheel behaviour, I tried and indeed just hovering a window the scroll wheel scrolls in the window. I may be totally wrong, or behaviour may vary depending on mouse driver and settings. I also have a new mouse keyboard combination, since friday my CTRL key was stuck and that's unbearable, so I bought a new keyboard mouse set.

If you want to be sure you can scroll inside the memo editing window put the text cursor in there and use the keyboard arrow keys. That should always work.

Bye, Olaf.

 

[dmusicant]

I go to my Windows 7 Home Premium laptop and also have C:\data\ans folder with same DBF's and I have no such problems navigating or changing memo file data. Something crazy is up with the Vista machine. It would be nice to nail it down. I have made no changes to options in the VFP 9 installation. Absent another idea I think I'll install VFP 7.0. I don't think I have to uninstall VFP 9, I'll just let it be and install VFP 7, do updates, configure things with my config.fpw and PRG file (which sets the paths and then executes a startup program that launches an FPW 2.6a screen with many buttons and a few menu items). All this has worked from FPW up the VFP 9, but right now on the Vista machine it's not working. One of my other laptops has a Vista Business COA, and I did run that for a while and I don't recall special difficulties. I subsequently installed Win 7 Ultimate 64bit on that machine and I don't have difficulties running my Foxpro apps on it either.