Hi Iain, thanks for sharing your experience. What about a self contained service running on the server so you can access the SEQ data from a "local file". At first sight, all you have is modify the way you get/put your data firing the remote service. For sure, it's still better if we find a way that it works the way it was in 9.3. HopeItHelps, Uli Another option may be just a flat file with CSV logic; using the USEQREAD to process it line by line. But I assume that you have structured data already so you may not want to loose structures.

Doesn't seem to work from services either, so there doesn't appear to be a good way to 'share' the data across multiple clients using only one file. I've considered storing it as XML and reading/writing this using services. SEQ is slow anyway, so these files are not accessed except during the client startup to check the database is up to date etc. However, Compuware report (as is usualy the case) that they cannot get it to fail there, so I hope it's a configuration issue.

The message 'The storage control block address is invalid.' is a windows error message. The windows event viewer on the server might contain additional information.

I can't see any errors under event viewer. I may redesign the whole thing to use xml files and import the data into the database as part of the install, it would make looking this info up waaaay faster.

Hi Iain, i thought about a REMOTE service submitted to your server machine, so it works locally there. Have you checked that on your server you access all the 9.5 software now (perhaps it's a 9.3 9.5 mismatch there)?

I got that Uli, a service running on the server cannot write to the file (although it can read the data) . The same service, running on the client process (on the server) CAN write to the file, as long as the path is not redirected through userver. Okay, that sentence confused me, I'll try again. Running uniface.exe on the server machine (so client software on the server) and executing the services within uniface.exe can write directly to the file, but can't re-direct this via the [PATHS] section and [ENTITIES] section. Running the same service via urouter/userver, and debugging it on the server can't write to the file, with the same error message given when trying to re-direct the data only. So it appears that either my userver asn is incorrect, or userver.exe uses a different driver, or it's a login issue or something. To get the client to write, I copy the settings from my userver.asn into my client.asn, so I think it's set up correctly (particularly since the same assignment file, before upgrading to 9.5 worked correctly), similarly, the server and user are the same as before the upgrade. We try to avoid confusion of versions here, so after some preliminary testing in VMs, (in which this didn't come up) we uninstalled version 9.3 before installing 9.5, they are installed on completely different paths anyway (we're moving the code out of c:\\program files and into c:\\apps to try and get rid of issues with 32/64 bit installs.) So I'm pretty sure it's only running 9.5. Last night I ensured the server was unused, unpacked patch E114 again to ensure it's overwritten the software properly, and re-booted. So I think the patch is in place properly. I have one minor thought.... nope, copying in the dll from a 9.3 installation makes it worse, then it can't read the data file at all. Copying in the dll from an unpatched 9.5 installation exhibits this error. The IDF and userver.exe (presumably using the same dll), using the same uniface install, CAN both write to the file. It's just userver.exe....

Facepalm It's permissions on the file. I moved these folders as part of moving the info from c:\\program files to c:\\apps, and the all users permissions was not set to Write/Modify on these files any more (must have inherited from parent...) Changing the permissions and re-starting the userver processes allows update..... I'll get me coat.

I was gonna say...! I know down on the 8th floor, most of the 'ad-hoc' work is usually based on SEQ, simply because it's quick and easy. So I'd have been surprised that something was uncovered...

FiresongKt said It's permissions on the file. I moved these folders as part of moving the info from c:\\program files to c:\\apps, and the all users permissions was not set to Write/Modify on these files any more (must have inherited from parent...) Changing the permissions and re-starting the userver processes allows update.....

Hi Iain, on the contraty: just another point what to look for at first it's good to know that Uniface works fine. As Adrian pointed out: SEQ id ideal for just-test-situations

Nowadays I store configuration data in XML files. I create my data in a struct, do structtoxml and filedump. Reading is fileload and xmltostruct. If I have a matching component structure it is even easier: Writing is componenttostruct, structtoxml, filedump. Reading is fileload, xmltostruct, structtocomponent.