Tim,

Here is a followup.

I disabled Windows Firewall so there is no software firewall running.
I disabled the AV.
EDBMgr and the client is running on the same machine as the EDB server.
I'm connecting to the server as 127.0.0.1
When the computer is rebooted, the client and EDBMgr can't connect to EDB server.
There is NO "Start Server" in logevents.
There are no error messages in Windows logs
The EDB Service is running
The failure to connect occurs randomly (25%-50%) after the computer is rebooted. If it fails to connect, it will continue to fail unless the service is restarted.

It appears to me the EDB service runs but does not initialize so it will listen on the default port. It is like a zombie server.

Now for the good news. I may have found the problem.

In edbsrvr.ini I had "Server Name=ABCDEFSrvr" when the problem occurred. I had kept EDBSRVR.EXE as the name of the executable and never changed it to ABCDESrvr.exe.

A couple of days ago I changed Server Name back to EDBSRVR and it hasn't failed to connect yet (knock on wood). So it looks like it is working fine now. I will continue using this configuration for a week to see if the problem re-occurs.

Barry

One thing I forgot to mention. I have EDBServer defined so it will accept only encrypted connections. I don't know if that has anything to do with the problem or not.

Barry
EDB v2.11 B3 32-bit

Barry,

<< In edbsrvr.ini I had "Server Name=ABCDEFSrvr" when the problem occurred.
I had kept EDBSRVR.EXE as the name of the executable and never changed it to
ABCDESrvr.exe. >>

You don't need to change the name of the executable, and the Server Name has
no bearing on anything - it's just an identifier.

How are you starting the service ?  Can you send me a copy of your
edbsrvr.ini file that you're using (C:\Documents and Settings\All
Users\Application Data\Elevate Software\ElevateDB Server) ?

Tim Young
Elevate Software
www.elevatesoft.com

Barry,

<< One thing I forgot to mention. I have EDBServer defined so it will accept
only encrypted connections. I don't know if that has anything to do with the
problem or not. >>

That will only be an issue if you're trying to connect with un-encrypted
connections, in which case you'll get a different type of connection error
(not a Winsock error).

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

<How are you starting the service ?  Can you send me a copy of your
edbsrvr.ini file that you're using (C:\Documents and Settings\All
Users\Application Data\Elevate Software\ElevateDB Server) ?>

It looks like I may have isolated the problem. The only difference in the working edbsrvr.ini file and the one that fails is the location of the "Temporary Tables Folder".

a) The one that fails is set to:
Temporary Tables Folder=C:\Users\Barry\AppData\Local\Temp\

b) and the one that works points to:
Temporary Tables Folder=D:\Data\ElevateDb\ElevateDb_TempData

There were hundreds temporary files from other apps in C:\Users\Barry\AppData\Local\Temp\ including a few from EDB like (ComputerName1124496410113591SessionName46.CompanyIDX, *TBL, *Blb, etc.). Once I changed this to the directory described in b), the problem went away. I have been using directory b) for the past few weeks without a hitch.

It wasn't obvious to me when I was using directory a), which files belong to EDB and which ones didn't. So I think the problem can be alleviated by giving ElevateDb its own subdirectory for temp files, whether it is in C:\Users\Barry\AppData\Local\Temp\EDB\ or elsewhere. If the user has a problem with the operation of the EDB server (like I did) and there are extra files lying around in the temp directory after the EDB server has been shut down, then the files can be deleted to try and remedy the problem.

Barry

hello,
i had something similar at the customer site some time ago. did not happen frequently but from time to time ...
basically it was that the given temp-path was not correct anymore after a reboot.
i am not 100% sure but i think it was like this: strangely windows deleted the temp-directory and created a new one 'temp2' - which was the new temp-dir! so it is a bit different from your experience ...
another server-does-not-start issue could be solved with the advice from tim that in the service properties (windows) on the third tab (probably 'restore' - i do not have english operating system) the actions for error management should be given to 'run service again'. doing this for the first two errors solved most of the startup issues (happened mostly after microsoft patch day and automatic restart)

hope this is not too confusing

Barry,

<< a) The one that fails is set to:
Temporary Tables Folder=C:\Users\Barry\AppData\Local\Temp\ >>

Yes, there may be an issue with using a user-specific temporary files
directory from another account like the Local System account that the
service will execute under, by default.

I'm glad that you found the problem, and thanks for the update.

Tim Young
Elevate Software
www.elevatesoft.com