On 11/24/2015 10:34 PM, Jeff Cook wrote:
> http://www.howtogeek.com/howto/28609/how-can-i-tell-what-is-listening-on-a-tcpip-port-in-windows/

I suggest this which is more user friendly

https://technet.microsoft.com/en-us/sysinternals/tcpview.aspx

>    TCP    192.168.1.11:1787   XXX.109.87.xx:12010    ESTABLISHED     2604
>
> Where XXX.109.87.xx is my correct fixed IP
>        PID=2604 is EDBMgr.exe  BUT shouldn't it be my EDBSrvr.exe!!!!
>        192.168.1.11 is my correct LAN IP

No - this is client side of the connection. EDBMgr picks a port
dynamically so this is "EDBMgr that picked local port 1787" to connect
to remote XXX.109.87.xx:12010"

Raul

On 11/24/2015 10:34 PM, Jeff Cook wrote:
> Where XXX.109.87.xx is my correct fixed IP

That looks like an external IP (i.e. public ip)?

>        192.168.1.11 is my correct LAN IP

This is your LAN

Where is your EDBSrvr running on ? Does your server have 2 network cards
(192.168.1.11 and xxx.109.87.xx) or are you routing the external traffic
from firewall or such back to PC.

If edbsrvr is on 192.168.1.11 then i would start by connecting locally
first (make sure it's listening on all IPs - i.e. 0.0.0.0) using either
127.0.0.1 or 192.168.1.11

My other suggestion is to create a new empty config and catalog and have
edbsrvr use that - if you can connect to it OK over lan then you know
the issue is not edbsrvr (if only change was changing config dir) and
can troubleshoot catalog and unicode/ansi. If you cannot connect to it
either then issue is networking etc.

Raul

Jeff,

<< I have suddenly got this problem starting a server.
---------------------------
ElevateDB Server
---------------------------
ElevateDB Error #100 There is an error in the metadata for the
configuration EDBConfig (The object has been updated by a newer version
of the engine)
---------------------------
OK
--------------------------- >>

More than likely, your EDB configuration file is corrupt (or your hard drive is "going south").  Please email me a copy of both the EDB configuration file, and the .old version of the same, and I'll tell you what I can find out (.zip please).

In the meantime, you can try restoring the .old version of the EDB configuration file in order to get back to working order.  The timestamps on both files may give you an indication of what the issue is.

The other issue is most likely just a side-effect from the first.  That is, the EDB Server can't start, so it isn't listening for new connections.

Tim Young
Elevate Software
www.elevatesoft.com

On 26/11/2015 7:29 a.m., Tim Young [Elevate Software] wrote:
>
> More than likely, your EDB configuration file is corrupt (or your hard drive is "going south").  Please email me a copy of both the EDB configuration file, and the .old version of the same, and I'll tell you what I can find out (.zip please).
>

Resolution as below, thanks for all the help from a Who's Who of Team
Elevate:-

Hi Tim

No worry about the Thanksgiving delay - had delays myself too!

In the end, the solution was quite straight forward even though the
original cause is shrouded in mystery.

I'm lucky in that I had a cloud server with the same structure as my
damaged server.  Steps taken to fix:-

1.  Delete the existing EDBConfig files.
2.  Check EDBSrver.ini file points to correct place.
3.  Start EDBSrvr.exe
4.  Start two sessions in EDBMgr, one on local server and one on cloud
server.
5.  Copy and Paste the SQL for the database creation from the cloud to
local - checking paths are correct.
6.  Do same with Stores
7.  Didn't have to do anything with Jobs as my application creates Jobs
as required.
8.  Users and Roles...

I have 80 odd users and 100+ roles so I was sweating over this one.
However, I had already written a program that runs like a service and
replicates the Users, Roles and UserRoles between my cloud server and
local server.  This was written so that in the event of a catastrophe
putting our cloud server out of action, our programs could seamlessly
access my local server instead.  In this case the local server was the
problem, but as soon as the server was up and I had created the
administration user the user stuff got replicated automatically!  Only
thing lost was the date of the last password change.

Cheers and thanks for your help

Jeff

On 29/11/2015 5:37 a.m., Tim Young wrote:
> Jeff,
>
> Sorry for the delay - Thanksgiving got in the way.
>
> << I can't use the EDBConfig.EDBCfg.Old file as it is zero bytes! >>
>
> Yeah, those configuration files are not valid.  A brand-new
EDBConfig.EDBCfg file should be 208 bytes, and that one is only 56 bytes.
>
> << Anyway ... I have no backup situation at this stage unless I can
pinch the .EDBCfg from a colleague's computer.  Would that work? >>
>
> How much customization is done in the EDB configuration in terms of
users, roles, databases, stores, and jobs ?  Is it a lot, and do you
have any programmatic way of creating most of it ?
>
> The reason for this corruption is most likely an improper shutdown
that has corrupted the file system, something environmental like AV
software that is interfering with file creation/copying (reason for the
zero-byte .old file), or hard drive issues.

Jeff Cook wrote:

> In the end, the solution was quite straight forward even though the
> original cause is shrouded in mystery.

Key question for the rest of us: Is there an automated backup option we
could use to help with such things? My EDB database on our web server
has an hourly backup made, and then that file is replicated to another
computer in the office. But is the catalog included? What do I have to
make sure is backed up to be able to recover nicely? Are the files in
use 24/7 that might stop a backup?


--

Matthew Jones

Matthew

>Key question for the rest of us: Is there an automated backup option we
>could use to help with such things? My EDB database on our web server
>has an hourly backup made, and then that file is replicated to another
>computer in the office. But is the catalog included? What do I have to
>make sure is backed up to be able to recover nicely? Are the files in
>use 24/7 that might stop a backup?

If you're using the built in backup system via a job then you need to have the INCLUDE CATALOG switch.

My understanding is that ElevateDB will restrict access whilst the backup is in process but it shouldn't be halted or prevented from starting once its grabbed access. IE a long running process may prevent it from starting until it completes but normal operation should be fine.

I have my email server running 24/7 and a job to back up the database once a night (cycles the file name through the days of the week but uses the same store) and it seems to be working OK.

Roy Lambert

Roy Lambert wrote:

> If you're using the built in backup system via a job then you need to
> have the INCLUDE CATALOG switch.

Thanks - I appear to have that. I shall rest easy. 8-)

--

Matthew Jones

On 12/1/2015 5:46 AM, Matthew Jones wrote:
> Thanks - I appear to have that. I shall rest easy. 8-)

But have you tried to do a (test) restore ?

It's not the backup you really need

Raul

Raul wrote:

> On 12/1/2015 5:46 AM, Matthew Jones wrote:
> > Thanks - I appear to have that. I shall rest easy. 8-)
>
> But have you tried to do a (test) restore ?
>
> It's not the backup you really need


I have actually, but not for a while.

--

Matthew Jones

On 2/12/2015 4:12 a.m., Matthew Jones wrote:
> Raul wrote:
>
>> On 12/1/2015 5:46 AM, Matthew Jones wrote:
>>> Thanks - I appear to have that. I shall rest easy. 8-)
>>
>> But have you tried to do a (test) restore ?
>>
>> It's not the backup you really need
>
>
> I have actually, but not for a while.
>

And remember from the OP that the database backup, with or without the
catalog was NOT the problem.

I have backups running on a user defined schedule using jobs as Roy said
- mine also go off site by using the the local server to ship the
backups to a server running in the "cloud".

The problem was that these backups did not include the configuration
files, so I lost the users, jobs, roles etc. and my backup systems
outside let me down. Luckily I could reconstruct everything once I knew
how.

So I'll probably set up a job to send the config files to the server
periodically.

Cheers

Jeff