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!

read-ony problem after server migration 2

Status
Not open for further replies.

axslinger

IS-IT--Management
Jul 10, 2000
103
0
0
US
Hi all,

First, I am NOT a VFP guy. In know nothing about it. I am a retailer/IT services provider and have plenty of tech savvy, however this one has be stumped.

Scenario: New customer needed a new server. Old server: Netware 5.x, NDS, IPX. HD almost full.

New server: Windows Server 2003 Standard, 5 licenses.

They were running a VFP app written by God knows who. Hes not around anymore.

Workstations have no less than 5 drive mappings to the Netware server. One is sys/apps, which contains what I presume to be a VFP app/database. They call it project4. Inside that folder is a Data folder and a slew of other folders.

They have a VFP shortcut on their desktops that points to G:\VFP6...\ (don't remember the exact path, just that its the VFP folder).

Basically what I did was duplicated the entire directory structure on the new server, copied the data over then duplicated the drive mappings on a test workstation. Heres where the fun begins...

I can launch their VFP app, it prompts for a password and accepts it, but in the upper-right corner of the app window I get a message, while its loading, saying that the table will be opened in read-only mode. Then when the app is loaded, the edit buttons on the bottom of the window are ghosted out. Just to verify that it wasn't a simple permissions issue, I went to the server and gave the Everyone group full control. No change. I gave individual users full control...no change.

Not being a Foxpro guru, I really don't know where to go from here. This is a case of a business building their business around this app and not having anybody to administer it.

I also noticed that the workstations had a buinch of what appeared to be indexes and other "database" type files in the root of their C: drives. They may not have anything to do with anything, I really don't know.

Any light you can shed on this would be appreciated.

Brian
 
First SWAG - did you verify that your tables are not in read-only mode (from WE attributes)?
 
Brian,

This is going to be a tough one to crack, especially as you are not in a position to give us any technical VFP-related information.

However, I can tell you that there is probably nothing wrong with the way that the application itself has been installed. It's not a question of missing run-time files, or anything like that. If it was, you wouldn't have been able to log in, and you wouldn't have seen the little message in the upper right corner (which is what we call a "wait window"; this is a VFP-specific type of message).

It's much more likely that the programmer has intentionally put the system into some sort of read-only mode, based on some settings that they've detected. It might be based on the way you logged in to the app, or some other configuration detail on the new system.

You say you gave everyone full control. Do you mean you did that at the operating system level? If so, it's possible that the application has its own system for permissions and access control. And that when you logged in (to the application), you logged in as a user who has only limited, read-only, access.

If I'm right (but it's only a guess), you'll have to figure out how to log in as an administrator so that you can alter the permissions.

Ultimately, the only sure way to deal with this problem is to go back to "God knows who", or, given that's not possible, find the source code and give it to a VFP programmer to sort out.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
I think I would quickly check that the file attributes haven't become read-only in the migration - how did you transfer the data across?

Secondly, look into opportunistic file locking on the server and workstation - it doesn't *sound* like that from your description, but it could be.

Last suggestion of the day, check the workstations - make sure that the users have (on a temp. basis if you like) full access rights to the whole of their C: drives, it could be that the system needs to make temporary files or somesuch and can't.

Good luck

Regards

Griff
Keep [Smile]ing
 
Thanks for the ideas. After a while your brain kind of "locks". I'm thinking the issue with local Admin rights could be the issue. Will let you know.

Brian
 
By WE I meant Windows Explorer, I had the same idea as in the first paragraph of GriffMG response.
 
Brian,

Please come back if you get any more information.

I would emphasise my earlier point ... that this is something that the programmer has consciously and deliberately done.

I doubt that it's simply a case of admin rights or permissions, or of a file attribute being set to read-only. I can't imagne many VFP programmers testing for those conditions, and then greying out their edit buttons accordingly.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Ok, I have been digging into this a bit more. What I did was tried to open the database locally on the server and it opened...but couldn't find some other files...makes sense since I didn't created the shortcut with the correct command line.

Then, still on the server, I mapped all of the same network drives to the local shares to duplicate the network environment and lo and behold, I got the read-only error. So, it was a Sharing issue, not necessarily a "security" issue. Since I was doing this remotely using remote desktop, I need to test it from a workstation but I believe I'm making progress.

FWIW, what I did as a test was try to delete one of the files (*.pjx). I could delete it locally through C: but I couldn't delete it locally going through the mapped G: drive. That was sort of my "litmus test" as to whether it was a sharing/security/network issue. Or course I restored the file. :) I'll let you know how it pans out.

Brian
 
what I did as a test was try to delete one of the files (*.pjx)

Just for your information the *.pjx file is not part of the runtime application, it is part of the source. It is the recipe for how to create the EXE. So it makes for a good test of your theory.

pamela
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top