Hi Guys,
Hoping for some help on this one.
We have a problem where a user can go into the DataEase 652 app with no problems to begin with. But after indeterminate time (could be 10 mins to an hour), they start getting Relationship errors. They then try to re-organize but bomb out with a ‘Unknown Error on Disk Drive’ error part way through.

If the user logs out and goes back in, they will not be able to use the system properly and will continue to get errors and bomb outs. The only resolution we have found so far, is to delete the Windows user profile off the pc and then log back onto the Domain to recreate it (they are on a domain).
After doing this, everything is ok again for a while (back to the state at the beginning).
Its almost as if the profile gets corrupted somehow, but we have never experienced anything like this?

This is a Belgium Company , and we have the system running Belgium with no errors using Belgium(Dutch) regional settings . Their sister company in Germany is running the same app but with the above profile problems , the two sites are linked over a VPN and the PDC is in Belgium. The German server is a member server on the forest. There are two physical servers , one at each site , and the Germany P.C's are set up for German regioanl settings.
Any help would be appreciated as i think now we have exhausted most avenues starting with cabling etc.

Richard Randle

It sounds like memory going corrupt or something breaking the connection to the server. Unknown error on disk....indicates some kind of I/O error. It is a bit of a red herring, but that is what it indicates. Losing drive mappings?

Has this ever worked properly? If so, I would suspect hardware problems. NIC perhaps.

Hi Phil ,
thanks for the reply .
we have got one laptop there working , we dont know how why this is ok , we are just comparing ntuser.dat files from the two users.
To add to complications , the domain policies for the forest are massive and could be picking up a policy from anywhere , as it is not our server we do not want to mess about too much with global policies.

i must admit , i have never come across anyting like this before , and as you know dataease is "twitchy" but there is nothing we havnt been able to sort out or find before.

Richard

Hey, Richard,

I never found DataEase to be 'twitchy', only different rules enforced on varying server operating systems. As long as you address "all the usual suspects" and provide users full rights to the data dir and any temp dir folders you are generally going to be all right.

Mixing things as you are doing must introduce many, many more variables that no one can sort out. Even M$ would throw up their hands and suggest moving to SQL Server.

Why not dedicate a terminal server or add a Citrix farm to serve all users? In a Windows world a dedicated server eliminates thousands of problems.

First the software to run your business
Second the operating system to run your software
Third the server operating system to support your users
Fourth the hardware needed.

What are your priorities?

Phil Hi,

We have ruled out all the "usual suspects". Thanks for your suggetsions. Our netc step inRDP to the master server in belgium from germany.
Unfortunately our hands are tied with regarsd to the netowrk set-up- the client is in charge.

Having worked through the standard issues with DFW & Networks we have narrowed the issues down to User Profile / domain plicies. But are totally flummoxed.

Cheers

Richard
Technical Director
Sumari Business Systems Ltd

There is a bug in DFW that results in unknown relationship errors. It happens when the relationships form is "busy" and a workstation fails to get a lock on it. Rather than retrying, it just fails and thinks that there is no relationship. By busy, I mean that there are a bunch of people using it, or a bunch of locks are getting set and, possibly, not getting cleared. However, this should not be the cause of any "corruption".

Your post offers brings up a lot of questions.

Is this a stand-alone application on a workstation or on a server?
If it is a shared app, how is it that someone can reorganize the relationships form?

If the person as a problem do they exit the app and come back into it before trying to reorganize something?

Is this the only DFW database in use?

Is there any chance that the computer where the database resides has a hardware caching controller on the hard drive, if so, then not all the writes may be going through which may very well result in errors stating that something needs to be reorganized.

Is the database ALWAYS being locked when any changes to forms or relationships are made?

Richard,

My network experts are Nick Jones here: http://www.njt-tx.com
or Gene Kern at http://www.waketsi.com

These guys are good and worth a try.

Hi Graham/Phil,

I am a colleague of Richards, but as he is out of the office today i will try and answers your questions as best i can. Thanks for your input so far.

We are fairly certain that the problem is more of a network/policies/user profiles problem rather than DataEase as i have extensively tested the app here and cannot replicate this problem (even gone so far as to copy that users profile folders onto a machine here with the same regional settings etc).



Both configurations have been tried. The App was originally on a server, but as a test we moved it to a workstation and ran locally, the problem persists!



Now for the strange part! The only way to re-org is for the user to log off Windows and then back on with another account and enter DE with an higher account that has ability to re-org.
If the user tries to come out of DE and go back in with a higher DE account, but still logged on with the same Windows account, it will not work.

The error they get is 'Unknown error on disk drive 'X' while writing, Check and correct if possible and retry' (whilst trying to re-organize).

We are sure that the problem does not lie with DE, its almost as if the Windows profile for the user is corrupt in some way.

f they delete the profile off the local pc and then log back on (with domain account) so it is recreated at time of logon, we end up back at square one, everything works fine for a while (seems to be 10-30 mins) and things start going wrong again (timeouts and unknown relationships).

As Richard said we have ruled out all usual suspects (pretty much triple checked!), but everythings ok.

We are curious to know if anyone else has ever experienced something like this.

Thanks again.

Sounds like a classic case of SMB signing not being specified in Group (or overridden by domain policy) SMB signing is enabled for all Domain controllers from 2000 Server onwards.

So, for example if SMB signing is enabled at the client and disabled on the server, a Level 2 Oplock may be granted at the Servers discretion preventing Read / Write access. This has the same effect as shoving DFW’s 3 main lan files (config.dat, denet.ovl etc.) in a read only directory)

So the domain policies require a rethink - cannot be done in individual registry settings.

John
ShopEase

That is understandable. The process or reorganizing a file requires that a new file be created, the data transfered to it, and the old file deleted. If a user does not have full rights to a directory, they cannot do that. In the normal course of things, an average user will not need to reorganize anything, but that doesn't mean that they might not need to create or delete a file (e.g. temp files). I've never experimented around to see what would happen if a user didn't have full rights to the data directory, but they should have it. just the same. I can understand why they don't have Full Control on all directories, but they should have it for the data directory.

Where are the temp directories located? Server or locally?

Thanks for the replies.

To answer your questions - The temp folders are local (C:\Temp) and users have full permissions over the data folder.

But some ground may be being made. Turns out the problem may be network hardware related after all. The problem does not show up if the user experiencing the problems logs in with their account at another location at the site, so this implies cabling/switch/patch panel problems to us.
Although the cables from the actual pc to the wall socket were checked/changed, nothing beyond that was, so now they are doing some testing!

Fingers crossed and thanks again for your help, will let you know if its resolved.