From 32 Bit 2003 servers we cannot access a VFP DBC moved from a Server 2008 file server to a 2012 server
We've moved our data from a file server with MS Server 2008 operating system to a new file server with Server 2012 operating system. Users on 64 bit Windows 7 systems are not having issues running our VFP app after moving the DBC and other files required by the VFP app to the 2012 server. However, from multiple 32 bit MS Server 2003 systems we can no longer run that same app. On one of those 32 bit 2003 servers, if I try to open the DBC on the 2012 server within VFP I get this error, "Error reading file ...\isviews.dcx." Within VFP on that same 2003 server I can open DBF files on the 2012 server that are not contained with the DBC. It appears that the DBC or DCX files, now on the 2012 server, are not accessible from the 32 bit 2003 servers and this is what is keeping us from being able to run our VFP app on these servers.
ASKER
To reiterate the issue:
The only problem is that no users/admins can access the isviews.dbc file, recently moved from a 2008 server to a 2012 server, from the 32 bit 2003 server. All users/admins can access the file on the 2012 server from the 64 bit Windows 7 systems.
I copied the inaccessible isviews.dbc from the 2012 server to a 2003 server and all users can access it there from the 2003 server.
This is sounding more like a security issue than anything. We initially had problems using RDP to access the 2012 servers from the 2003 servers, but there was a work around for this. It seems to me like there is something within the isviews.dbc blocking the 32 bit 2003 server from accessing it. Remember, it is accessible for all users from the 64 bit Win 7 systems.
The only problem is that no users/admins can access the isviews.dbc file, recently moved from a 2008 server to a 2012 server, from the 32 bit 2003 server. All users/admins can access the file on the 2012 server from the 64 bit Windows 7 systems.
I copied the inaccessible isviews.dbc from the 2012 server to a 2003 server and all users can access it there from the 2003 server.
This is sounding more like a security issue than anything. We initially had problems using RDP to access the 2012 servers from the 2003 servers, but there was a work around for this. It seems to me like there is something within the isviews.dbc blocking the 32 bit 2003 server from accessing it. Remember, it is accessible for all users from the 64 bit Win 7 systems.
Why there should be "something within the isviews.dbc" if the error message says "Error reading file ...\isviews.dcx"?
Your system administrator should be able to monitor the network requests and tell what's the reason of the file inaccessibility.
I have to ask again: Are you able to create/delete files in the 2012 data folder from the app running on the 2003 server?
Your system administrator should be able to monitor the network requests and tell what's the reason of the file inaccessibility.
I have to ask again: Are you able to create/delete files in the 2012 data folder from the app running on the 2003 server?
What about domains? Which server is the primary domain controller and are they both part of the same domain, now?
>Remember, it (the 2012 server dbc/dcx) is accessible for all users from the 64 bit Win 7 systems.
If you say all users, does that mean users using the same account on 64 bit clients can access the data and can not, if logging in to a 32bit client?
Like Pavel I would judge this as OS problem, if data access is not native, but eg through sybase 64bit drivers you would have a very strong reason bound to the bitness of the OS. Otherwise it's not as easy to migrate to another server, than it is to add clients to a domain. Think through what happened and which server now is handling user permissions/profiles, active directory.
Bye, Olaf.
>Remember, it (the 2012 server dbc/dcx) is accessible for all users from the 64 bit Win 7 systems.
If you say all users, does that mean users using the same account on 64 bit clients can access the data and can not, if logging in to a 32bit client?
Like Pavel I would judge this as OS problem, if data access is not native, but eg through sybase 64bit drivers you would have a very strong reason bound to the bitness of the OS. Otherwise it's not as easy to migrate to another server, than it is to add clients to a domain. Think through what happened and which server now is handling user permissions/profiles, active directory.
Bye, Olaf.
ASKER
I am working on this right now with an network admin. To answer pcelba questions - I can't create files from the app on the 2003 server to the folder on the 2012 server because I can't run the app on the 2003 due to isviews.dbc being inaccessible. However, I can create documents in the folder using other apps, like Notepad, etc. You are correct the error refers to the dcx file - I get this when trying to Modify Database isviews.dbc or Use isviews.dbc.
FYI, I installed VFP 9 on a 2012 server today and have full accessibility to the isviews.dbc I cannot access from the 2003 server.
To answer Olaf's questions - We moved the data from a 2008 HyperV server to a 2012 HyperV server. The file server isviews.dbc is on is a 2012 VM. The 2003 server is a stand alone tower. Both the VM and the 2003 server are on the same domain. The domain controller is another VM. This issue is occurring at one of many branches in a large corporation. This branch domain controller is a read/write secondary with a global catalog. The FSMO roles for the domain reside at the corporate office is Dallas. This configuration cannot change. Correct, users can access the data from 64 bit systems (Server 2012 and Win 7), but not the 32 bit 2003 server.
FYI, I installed VFP 9 on a 2012 server today and have full accessibility to the isviews.dbc I cannot access from the 2003 server.
To answer Olaf's questions - We moved the data from a 2008 HyperV server to a 2012 HyperV server. The file server isviews.dbc is on is a 2012 VM. The 2003 server is a stand alone tower. Both the VM and the 2003 server are on the same domain. The domain controller is another VM. This issue is occurring at one of many branches in a large corporation. This branch domain controller is a read/write secondary with a global catalog. The FSMO roles for the domain reside at the corporate office is Dallas. This configuration cannot change. Correct, users can access the data from 64 bit systems (Server 2012 and Win 7), but not the 32 bit 2003 server.
ASKER
The domain forest function level is Server 2003.
ASKER
One more thought... I have two simpler VFP apps than the one that is dependent on isviews.dbc. Both of these apps are dependent on other files located in the same folder as isviews.dbc. Both apps are running without any issues.
Note that I previously stated that from the 2003 server I can open System.dbc, but not isviews.dbc which is in the same folder.
There is something about just that one file, isviews.dbc or dcx that seems to be having a compatibility issue with being on a 64 bit 2012 server while trying to be accessed from a 32 bit 2003 server. If moved isviews.dbc is accessible from the 32 bit 2003 server on itself and on the previously used 64 bit 2008 server.
This is a weird one!!
Note that I previously stated that from the 2003 server I can open System.dbc, but not isviews.dbc which is in the same folder.
There is something about just that one file, isviews.dbc or dcx that seems to be having a compatibility issue with being on a 64 bit 2012 server while trying to be accessed from a 32 bit 2003 server. If moved isviews.dbc is accessible from the 32 bit 2003 server on itself and on the previously used 64 bit 2008 server.
This is a weird one!!
A dbc is a dbc, if a system.dbc works and your isviews.dbc not, look into details of file security difference on the two dbc, the two dcx and the two dct files.
It's also easy enough to replace a DBC/DCX/DCT file from a backup, as it holds no data itself, just the meta info about the database tables. In case of a dbc holding views, as isviews.dbc seems to be, that will contain all the view definitions and sql. SQL queries are code you should put to clients, not on a server. If you at least have a configuration of the app using a view dbc, you could configure that to a local folder. But you first need to ensure it really only contains view definitions.
Bye, Olaf.
Edit: Connecting the thought about view dbc and your original error report about the error message: "Error reading file.." - that error is error 1104 and not a problem due to vfp locks or view usage, that would cause another error for long running views.
So your detail problem is something else than the typical problem of a shared views dbc, but in the light of the problem it would of course also be solved, if that dbc was moved to a local client side folder anyway.
Plus: error 1104 really does point to an OS problem with the file.
It's also easy enough to replace a DBC/DCX/DCT file from a backup, as it holds no data itself, just the meta info about the database tables. In case of a dbc holding views, as isviews.dbc seems to be, that will contain all the view definitions and sql. SQL queries are code you should put to clients, not on a server. If you at least have a configuration of the app using a view dbc, you could configure that to a local folder. But you first need to ensure it really only contains view definitions.
Bye, Olaf.
Edit: Connecting the thought about view dbc and your original error report about the error message: "Error reading file.." - that error is error 1104 and not a problem due to vfp locks or view usage, that would cause another error for long running views.
So your detail problem is something else than the typical problem of a shared views dbc, but in the light of the problem it would of course also be solved, if that dbc was moved to a local client side folder anyway.
Plus: error 1104 really does point to an OS problem with the file.
I installed VFP 9 on a 2012 server todayWHY on 2012 server?
You should test the file accessibility from 2003 server so VFP 9 should be on the 2003...
You don't need to install VFP 9 you just need to copy following files (allowed by EULA for testing purposes):
VFP9.exe
VFP9enu.dll
msvcr71.dll
and possibly also:
msvcp71.dll
gdiplus.dll
and VFP will work from 2003 server and you may try to open files on 2012...
If the DCX file if wrong somehow then delete it (or rename it) and open the database again in VFP 9 (from 2003 server!) by
OPEN DATABASE d:\path\isviews && d:\path\ represents the mapped 2012 folder visible from 2003 (you may use UNC path)
VFP will create a new DCX file automatically. It is just an index file for the DBC/DCT.
ASKER
I tried everything. Then I shut down the entire network last night making sure there were no systems accessing any files used by the VFP apps. After bringing the network back up I re-transferred all files from the 2008 file server to the new 2012 server. SOB, but all is well. The initial migration was handled by their corporate IT, not my guys and I bet there were VFP apps open and accessing their dependent files during the move. This was not supposed to be possible.
Frustrating, but everything is working again now, Thanks guys. Any final thoughts?
Frustrating, but everything is working again now, Thanks guys. Any final thoughts?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Is it possible to create any file in the data folder?
Is it possible to copy the .DCX file from the data folder to Server 2003?
Do you have sufficient access rights to all data folders/files?
This does not seem to be FoxPro problem but rather OS/access rights problem.