fearandir said ZIP error:(IOSERR_FILE_READ_WRITE) on [s:\\uobj.dol] '' - File read/write failure At same moment if you perform a $fileexists(s:\\uobj.dol) all seems ok.   Regards   Sergio  

Hi Sergio Maybe you don't have the right to write to UOBJ.DOL Sometimes UnifAce want this rights, even if there no sense behind this Ingo

istiller said

fearandir said ZIP error:(IOSERR_FILE_READ_WRITE) on [s:\\uobj.dol] '' - File read/write failure At same moment if you perform a $fileexists(s:\\uobj.dol) all seems ok.   Regards   Sergio  

Hi Sergio Maybe you don't have the right to write to UOBJ.DOL Sometimes UnifAce want this rights, even if there no sense behind this Ingo  

Nope. I changed file permissions and did not work

fearandir said Nope. I changed file permissions and did not work  

So, check it they "hard" way :-) But first: Is this the first call to UOBJ.DOL? Or cann you call othe procedures but not PC_PONER_CEROS ? Download this tool from Microsoft https://technet.microsoft.com/de-de/sysinternals/processmonitor.aspx Then start it and apply a filter like "processname begin with uniface" Now start Uniface and go to the statment, which cause the problem: call PC_PONER_CEROS() in procmon clear the output and then try to step into PC_PONER_CEROS. Procmon will show you every call to the filesystem. Are there any "dubious" errors? Ingo

istiller said

fearandir said Nope. I changed file permissions and did not work  

So, check it they "hard" way :-) But first: Is this the first call to UOBJ.DOL? Or cann you call othe procedures but not PC_PONER_CEROS ? Download this tool from Microsoft https://technet.microsoft.com/de-de/sysinternals/processmonitor.aspx Then start it and apply a filter like "processname begin with uniface" Now start Uniface and go to the statment, which cause the problem: call PC_PONER_CEROS() in procmon clear the output and then try to step into PC_PONER_CEROS. Procmon will show you every call to the filesystem. Are there any "dubious" errors? Ingo  

Any action that implies read the DOL file fails. Global procs, glyphs, etc... PC_PONER_CEROS is a simply a common process that runs very often in our application

fearandir said Any action that implies read the DOL file fails. Global procs, glyphs, etc... PC_PONER_CEROS is a simply a common process that runs very often in our application  

So put a DEBUG in first place (before ann access to DOL) in your startup shell. Start the proc-monitor and then your application. Is there any hint if and how the DOL will be read?   Ingo

istiller said

fearandir said Any action that implies read the DOL file fails. Global procs, glyphs, etc... PC_PONER_CEROS is a simply a common process that runs very often in our application  

So put a DEBUG in first place (before ann access to DOL) in your startup shell. Start the proc-monitor and then your application. Is there any hint if and how the DOL will be read?   Ingo  

proc-monitor just says: class: File System Operation: Readfile Result: NETWORK ERROR Path: \\\\10.12.19.210\\minforms\\uobj.dol   if i start a new window and rename DOL file in server, ir works... maybe  OS/SAMBA problem?

Any idea? 

If Windows 7 or Windows Vista is involved the following might help: disconnected drives , connection to drive not recognized Suggestion from Microsoft:  https://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx To configure the EnableLinkedConnections registry value, follow these steps: 1. Click Start , type regedit in the Start Search box, and then press ENTER. 2. Locate and then right-click the following registry subkey: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System 1. Point to New , and then click DWORD Value . 2. Type EnableLinkedConnections , and then press ENTER. 3. Right-click EnableLinkedConnections , and then click Modify . 4. In the Value data box, type 1 , and then click OK . 5. Exit Registry Editor, and then restart the computer. Peter

We learned the hard way that DOL & URR should be stored locally to preserve performance and continuity. Back in the days we still used DOL & URR, we copied them (having a version in their name) to the local working folder where messageframes and dumpfiles where stored.   Since 9.7 we switched to standardized deployment: we create 1 UAR for our application and store/cache it locally under appdata. Only once scanned by antivirus.  Never had such great performance with uniface :-)

PBeugel said If Windows 7 or Windows Vista is involved the following might help: disconnected drives , connection to drive not recognized Suggestion from Microsoft:  https://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx To configure the EnableLinkedConnections registry value, follow these steps: 1. Click Start , type regedit in the Start Search box, and then press ENTER. 2. Locate and then right-click the following registry subkey: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System 1. Point to New , and then click DWORD Value . 2. Type EnableLinkedConnections , and then press ENTER. 3. Right-click EnableLinkedConnections , and then click Modify . 4. In the Value data box, type 1 , and then click OK . 5. Exit Registry Editor, and then restart the computer. Peter  

Thanks Peter but we use Windows 10. Anyway, i tried and i got the same error.

Hello just for info,  I got this error sometimes after a network problem on dol file et pratt (using the $seq for pratt file) running under windows server 2012, the client are either connected through tse , so running on the same machine or accessing  these files through a mounted network drive from another machine each time, i tried several solutions to make it work :  recreate the mounted drive, close all sessions if tse and at last if it doesnt work, restart the server error on pratt file arrived very frequently with network problems, so I moved the pratt table into data base (work around but stopped the end user calls) can't try now the uar files, maybe it will solved the problem? Dominique

mpservices said Hello just for info,  I got this error sometimes after a network problem on dol file et pratt (using the $seq for pratt file) running under windows server 2012, the client are either connected through tse , so running on the same machine or accessing  these files through a mounted network drive from another machine each time, i tried several solutions to make it work :  recreate the mounted drive, close all sessions if tse and at last if it doesnt work, restart the server error on pratt file arrived very frequently with network problems, so I moved the pratt table into data base (work around but stopped the end user calls) can't try now the uar files, maybe it will solved the problem? Dominique  

Yeah if we change the deployment method or if we copy the dol file from server to pc everytime we log on the application the problem will be solved. The issue is to know why uniface tells me that can not read the DOL file after a short network problem, even when the communication channel is restored. Thanks Dominique. Sergio

Hi all I think i found the solution: https://unifaceinfo.com/docs/0905/Uniface_Library_HTML/ulibrary/$MEMORY_8D9D9A7751CA89E2C58D1397BFBB52AA.html With the configuration setting $MEMORY ZIP=ALL you specify uniface to keep the DOL (zip) file on memory until application ends. So, it is no need to access the file over the network.   I still do not understand why with the default  settings and the network communication restored you can't read the file but whatever...   For some reason the DOL file keeps blocked on filesystem no matter the $MEMORY ZIP value Greetings,   Sergio

forget my last post. That solution allows to call global procs, glyphs, etc... but for some reason all the ACTIVATE statements crashes the application. i am really lost 

Take a look at this and see if it helps. https://technet.microsoft.com/en-us/library/cc770902(v=ws.11).aspx

Hi all. $MEMORY ZIP=ALL  is not working as  documented... Do not store the the whole URR file into memory as it indeed do with the DOL file....   This behaviour causes a fatal error each time uniface tries to read a signature. Greetings.