table locations of .dbc in a networked environment 1

[jamesrav]

after getting my stand-alone VFP 9 program running as desired, I now want to make it accessible to several users. All the tables in the .dbc reference paths on my developer machine (ie c: drive paths). The 'server' will be seen as the X: drive by the various workstations (on which the .exe will be installed, on each workstation). So not surprisingly, when I start the program on the workstation, it does locate the .dbc on the X: drive, but I get a "cannot resolve backlink" error - I'm sure this is related to the fact that the program is anticipating table locations using the developer c: drive paths that the .dbc specifies. So how do I overcome the X: drive / C: drive confusion? I can't see having to re-create the .dbc using X: drive paths on each workstation (and VFP isn't installed on them anyway).

As an aside: if I instead start the application from a workstation using the .exe on the X: drive (something I don't want to do), it gives me an error regarding not being able to find a .dbf file on the c: drive (which is the path specified in the .dbc of course). So this method does not work either.

 

[Olaf Doschke]

the backlink to a dbc within a dbf is a relative path, so moving from C:\ to X:\ shouldn't become that issue. Backlinks only need to be a full path with drive letter, if you'd design a DBC with DBFs on a separate drive than the DBC in the first place.

What causes looking for a dbf on C:\ most likely is the data environment of forms.

Both things might come together here, but it's hard to say what exactly is going on. Programming for multi user has more pitfalls than these, but you'll see.

You should first find out why you can't open DBFs (or is it the DBC?) on drive X without errors. Just using the IDE and SET EXXCLUSIVE OFF (on by default within the IDE) you should be able to open DBC and DBF copied from C:\ to X:\ without problems.

Bye, Olaf.

 

[jamesrav]

EDIT 2: i was able to see how the concept works with a much simpler program, no problem accessing a networked table residing in the container from the workstation executable. Probably after some more reading and experimentation, I will come to a conclusion on how to proceed. The .dbc does validate okay ... if I cannot resolve the issue I will probably empty it out and add the 1st table accessed, if no backlink issue then add in the remaining tables.

EDIT: after posting this, I was able to launch the application from the x: drive, and that does appear to work. But the goal is to have a local workstation executable function properly.
____________

thank you Olaf, I'm thinking this will end up being simple to resolve. Just to be clear on a couple issues: on the developer machine, the data environment for forms does reference the database(container) for every table using the c: drive path of the .dbc on the developer. And every table in the .dbc shows a path that references the c: drive location. Since tables have to be physically somewhere, I assume that's not coming into play with respect to the workstation, which is looking for things on it's X: drive (which happens to be the developer C: drive - I'm just experimenting with this pseudo network). I did share the base folder that contains the development files (lets call it c:\oasis), and mapped that folder to the X: drive. There are no hard-coded paths for tables in the application. Once the default path in the application is set to the X: drive, do all the dataenvironment references to the specific path for the .dbc (c:\oasis) and tables within the .dbc (also c:\oasis) just 'disappear' in a sense, vfp and my application should not be concerned with those physical locations paths?

 

[Olaf Doschke]

There is no issue of any corruption. It's just unfortunate, for example, that dataenvironment objects remember the DBC path and therefore tend to look at C:\ always. You can eleminate that by temporarily renaming your database folder on C:\, so it can't be found. Then the data environment of forms will look along path for other locations of the DBC.

It's one of the unfortunate things of the DE for which I don't use it.

To illustrate this:

Here the DE object "mytable" (as all tables of the same DBC) has the full path as database property and that makes your EXE look for the database in its original location. It's what any good developer avoids: Hard coded paths. FoxPro forces this upon you.

One way to live with this is have the same path for dev and production data by mapping X: to different shares or during development have a SUBST (DOC command) mapping of X: to a folder of C:\, eg create C:\DriveX and put in the same directory structure there. The danger of that is forgetting to switch and testing on production data.

Another way suggested in Hentzenwerke books is to have code in the DE changing that path on the fly:

http://fox.wikis.com/wc.dll?Wiki~HowToChangePathInDataEnvironment

I just don't see that as maintainable solution, though. I rather like to have the fixed path having different meanings by different mappings and thus not needing to fix all DE objects database property at runtime.

Another very simple solution is not making use of the visual table (cursor) objects of the DE, but use the code section (Open Tables method of the DE) to [tt]USE myTable in 0[/tt] and let that open mytable from whatever DBC is currently opened by previous code (eg within main.prg), for example. Or [tt]Use mydata!mytable IN 0[/tt], if I have multiple database names. Alone that makes it possible to switch database location easily. As said this could already be part of the main.prg start code and this could read a location from an INI or DBF.

Bye, Olaf.

 

[jamesrav]

I certainly have learned a bit more about VFP while trying to 'fix' this issue. Just out of curiosity I wanted to see badly it would break the stand-alone version by deleting the Database from the project (not from the disk however). To my surprise it had no effect whatsoever after rebuilding the project and recompiling. Worked just as before ... so I copied that version of the program to the workstation, and to my amazement, it worked. A default value procedure for the table worked, so no functionality was apparently lost by removing it from the project. Baffling, or expected? Now since I'll need to occasionally modify tables in the now gone Database, I will need to add it back in at some point. But I guess if it fails on the workstation after doing so, I'll just remove it again. Seems weird but if it works, it works.

 

[Olaf Doschke]

>Baffling, or expected?

expected.

Just look at the database and table items in the project manager:

These little, crossed signs here tell the database and table are not included into the compilation, it's not included in the final EXE. If you right click here you'll find the context menu item "Include", which would remove that exclusion sign and include the database into the exe. But that would make it a readonly part within the EXE. Exclusion is a sensible default, isn't it? You want to work with data, don't you? Insert into it, update it.

The way your EXE knows where the DBC is is by the DE table objects database property I showed already. If you don't have code to open your database in main.prg or any init your forms DE will open it just in time. That's intended by VFP/MS, but not the way you should act if you want the database location movable.

The only reason for a database section in the project manager is for ease of working on the database within the IDE, it's the IDE keeping your DBC open and giving you easy access to tables within code not even having OPEN DATABASE before any USE of a table by its mere table name. Also, the calls of stored procedures are not found, when you remove the database from your project. So it's not a good idea to do that, it doesn't help in getting independent from its development location, too. This is not what hardcodes the DBC path. Making use of the visual table objects in the data environment of forms is hardcoding the DBC path.

So overall you have your database as part of your project, it won't matter much for the compilation besides cross checking the stored procedure calls your code makes can be found within the database. If you don't have such code, then your project doesn't need the datbase, but not having it will make database maintenance harder,unless you create a separate proect for that matter. But why? I even recommend puttin project documentation of doc(x), txt or any other file type into the project for sake of completeness. The project manager is your organizational tool, not just the tool to build your final EXE.

Bye, Olaf.

 

[jamesrav]

UPDATE AFTER POST: i did rebuild and recompile and no back link problem, so I feel confident the problem has gone away. It is interesting that temporary removal did seem to fix the problem, and adding it back
in didn't resurrect the problem. Thanks for your explanations, I had always wondered about the little circle - I think I even googled it a few times and never found what I wanted. Must have used a bad
descriptions.
_________________

thank you for that explanation, I will re-read it to understand every detail. I did out of curiosity put the Database back in, and recompiled (but not rebuild) and it still worked. I will try a rebuild to see if that has any adverse effect. If not, then it appears removing it had the positive effect of fixing or negating the back link problem. After removal I did add a new record to one table which uses a Field Validation procedure that auto increments a field, and that did occur properly - so I (naively) thought that the stored procedure was still functioning ... but now I recall that the programmer (I inherited this) also had the same exact procedure in the SET PROCEDURE prg file, so I now assume that procedure got used instead of the stored procedure (since you logically pointed out that the Stored Procedure in a Database should/must disappear if the Database is removed from the project).

Hopefully rebuilding will not cause the back link problem to come back, but if so I know I can (mostly) get around it by making some minor adjustments.

 

[Olaf Doschke]

I'm obviously not into the details of why there is a procedure name overlap with stored procs, it might have some reason to overload, but in general is a bad idea, of course. I don't see how that causes the backlink error, that is merely caused by opening a DBF, not from starting a procedure. The latter can only indirectly trigger the error, for example by opening a DBF from C: while the database of X: is opened would at least cause some confusion. But as long as the database on C: exists, opening a DBF from C: would open up that DBC, too, so you'd have both databases open. That again might also contribute to some confusion.

I doubt you have a real backlink problem as a defect of the DBF files. It'll just be some quirk for workstations not having the DBC on C:\ of course, but the path is stored relative unless there is no chance to compute a relative path between DBF and DBC it belongs to. So moving a DBC has no problem at all, but having both available on your dev computer might be a problem more than for clients not having it, and that in turn causes other problems: They get a problem with the data environment not finding the database.

I think you have to digest all this information one after the other, just notice there are several places of "backlinks" to the DBC and you need to know which is causing the error. The table objects within the data environment are NOT the tables themselves, their database property, of course, inherits the DBF backlink to its database when you add a table to the data environment, but the table object database property then is its own property you can access and overwrite (the solution I pointed to but dislike as hack fix is doing so), this is not changing DBF backlinks, this is setting the information of the data environment straight to the current situation, which differs during development and production use. The unfortunate thing is that the DE table object database property is NOT a relative path while the DBF backlink is, so it doesn't adapt to X:\ at runtime.

Bye, Olaf.

 

[jamesrav]

and you need to know which is causing the error

well fortunately there is no more 1976 error, at least not that I'm experiencing. When I send this to the customer perhaps the back link error will come back at their site, I hope not. I mentioned the identical stored procedure / regular procedure not as a possible cause, but simply that I assume the programmer originally had the code in the SET PROCEDURE prg file and then determined it would be better to have it as a stored procedure, and just never got around to removing it (in fact all the stored procedures have almost identical versions in the SET PROCEDURE prg file).

Now that I understand the .dbc concept and that's it's mostly a programmer 'helper' and not really a vital component, the fact that removing it fixed the problem (since you can't have a back link problem without a Database??), is not that surprising. Putting it back in had to be tried though, and I'm glad to report the problem has not re-appeared (and when it was happening it cropped up immediately, since a table is used in line 4 of the main form).

 

[Olaf Doschke]

Well, it's surprising to me removing and putting back the dbc to the project solves your problem. Having it in the project or not does not change any backlinks of files.

And of course the dbc is a vital component itself, it's just not vital to have in the pjx, unless you call stored procs. within it, which then cause warnings in build about not found procedures.

So, no, it's not at all natural you experience what you experience. If the problem comes back at your customer its likely a real backlink corruption within his database/tables.

Bye, Olaf.

 

[jamesrav]

I appreciate your responses, and yes it does seem to be working perfectly after the removal (and then returning the Database to the project). The stored procedure is definitely being used, I put it in a message just to verify that.

With that behind me, let me ask a somewhat off topic question: Their IT guy - and I'm no network expert - asked about using ODBC for this for "security reasons". When I explained that VFP has a built-in database and there's absolutely no need for ODBC, he seemed not to understand what I was saying. His concern was keeping the server "off limits" to the users on the work stations (ie cant copy files) ... but can't that be handled through some Administrative rights? Allowing a program to run (mine) that interacts with the server, but keeping the servers' X: drive (or just a mapped folder designated as X unavailable to the user - that would seem to be Networking 101 in terms of ease of accomplishing ??

 

[Olaf Doschke]

You can't really tackle that, VFP accessing DBFs is done with user permissions. There is a possibility of the VFP process impersonating an application user, but that's far too easy to break (eg any open file dialog opens up the permissions to application users). So there is no way to shrink access other than only allowing read-only access, if your users don't need to add/edit data.

If that's a prerequisite you'll have to rewrite for usage of a backend database like MSSQL Server.

Bye, Olaf.

 

[jamesrav]

UPDATE: I read this, sounds plausible if true. Basically 'hides' the folder containing the data from a user. If they didn't know the final path of the data they'd be in the dark as to where the data is

One more possibility is to move DBF files to a folder which is not directly accessible by ordinary users. The structure is following:
d:\sharedFolder\ - shared folder with full access rights
d:\sharedFolder\NoRightsFolder\ - subfolder with no access rights to ordinary users
d:\sharedFolder\NoRightsFolder\x12345678\ - subfolder containing the data with full access rights

The "x12345678" folder name is known to the application only and if the application does not show its name then users cannot open it because they cannot list the "NoRightsFolder" contents.

___________________

disabling all removable devices for writing? that leaves the possibility of emailing the data or uploading to a storage site - if internet usage is (potentially being) monitored - and employees know that - that seems like a good deterrent to most non techies. How was data handled during VFP's heyday? lots of small businesses had VFP programs in use, was the data 'open to take' by anyone back then?