Hi Team,
Testing Server/Remote mode at the Clients.  Has been working fine since 1400 today, then started throwing these 9999 error codes.  See attached.
Any thoughts on what could case an error code of 9999?

Regards & TIA,
Ian

Had the thought to look at the LogEvents Description in EDBMgr.
Seems 'An unexpected network error occurred.'

Ian Branch wrote:

<< Had the thought to look at the LogEvents Description in EDBMgr.
<< Seems 'An unexpected network error occurred.'

hi Ian, I had same errors on a customers server ... Found out that the database was connected through an unc path instead of local path on server. Changing the path to local solved that ... But worked only after reboot. Seems that some process has locked a dB file ...

Yusuf Zorlu
MicrotronX

Hi Yusef,
Thank you for your input.
The path is defined by the physical Server IP.  i.e. "\\192.168.1.35\ApplicationDrive\".
I can't use absolute paths because the Apps/data are accessed by people logging into the Physical Server using RDP, as well as others on the local LAN.

Regards,
Ian

Correction - The EDB Server does in fact access the drive via a local path. "C:\ApplicationDrive"
I was thinking of the Apps.
Apologies.
Ian

Ian,

9999 in not abn EDB error code.
Where did this log come from?

--
Fernando Dias
[Team Elevate]

On 3/18/2019 7:02 PM, Ian Branch wrote:
> Correction - The EDB Server does in fact access the drive via a local path. "C:\ApplicationDrive"
> I was thinking of the Apps.

So what is your setup exactly
- Are client exe's located on network share and they run it from there
- Apps themselves use C/S and edbsrvr OR do they also go direct using
file access with share as well

Using file shares can be trouble even if you just host exes there - in
addition to network issues windows might time out share access so you
might have weird execution errors due to that

Raul

Fernando,

<< 9999 in not abn EDB error code. >>

Error #9999 is basically EDB's way of saying that a) it didn't trigger the error, and b) it has no idea what the error is, or where it's coming from.

And yes, it's highly unusual to see these.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Raul,
There is a saga here.
All apps are located on the physical server, (64bit Win 2012 R2 server) as is the data.
Apps - C:\AppDirectory.
Data - C:\AppDirectory\Data

Most users call the apps via shortcuts to a mapped drive on their wkstn.
Some users log into the physical server via RDP and run the apps on the server.

ALL apps use a common application configuration file on start up to set their operating mode, i.e. Local or Remote.

There is no chance for there to be apps, different or otherwise, to be running in mixed mode.  There are 18 Apps in all of which 5 are key Day-to-Day apps used constantly.  The others are specialized function apps.

They have been running in Local (File share) mode since late 2016 as the Client didn't want to 'Risk' Remote mode.

It has taken me this long to convince him to at least test Remote mode, starting 3 days ago.  So far all the Users are loving it due to the quantum improvement in performance.

Ever since we went live in late 2016 we have been plagued by these very intermittent, loss of connect, couldn't find a file, apparent corrupted record, hiccups.  It would affect several different Apps at the same time however they may not notice if they weren't actually doing anything in the App at the time.I blamed the network, the Client naturally blamed the Apps.

They, the Users, became used to it and knew what to do when it happened to keep working, however I was never happy.

Moving to the Remote mode seemed to aggravate the consequences of one of these hiccups.

I became convinced it was a network issue when an app, running on the physical server via rdp, that simply uses a standard windows API call to see what files, app & data, are in use, failed.  It polls/updates every 5 seconds.
It failed with a network connection error, at the same time as Users experienced a hiccup in their Apps.

I explained all this to the Client but he is still not convinced.

Anyway, it has all been running 100% since yesterday morning and the Users are loving it.

I haven't enabled I/O Buffering as yet as I don't want to introduce another variable yet.

That's it.  Sorry for the long tale, hope I didn't bore you, but it was good to document.
Regards,
Ian

Thanks Tim.