Database postgress Event ID 0 from source PostgreSQL cannot be found

[Avat]

After a new installation the database stops to accept data from management console. For an example any value change in the maangement console does not stored.
We tried uninstall and reinstall but after 1 day or some hours same happens. We found the below error :

The description for Event ID 0 from source PostgreSQL cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:

ERROR: column "pv_failover_ip" of relation "s_sbc" already exists
STATEMENT: ALTER TABLE s_sbc ADD COLUMN pv_failover_ip character varying

Its on a vm latest vmware and microsoft server2016 with defaults settings

 

[Alphabetic]

https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

Is 3CX the only software running on your VM? Is it a vanilla install of OS? No AV?

 

[Avat]

yes only 3cx running on nothing else. And default conf only sip trunks and ext have setup up

• 3CX Version, Pro Annual 16.0.6.655
• Server OS, Windows Server 2016
• Is the 3CX Server Hosted and where? Cloud
• Provisioning Method: SBC
• Trunk Provider : Modulus
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

 

[Alphabetic]

If its a vanilla set up you might be quicker doing a backup, reinstall and restore.

 

[Avat]

If its a vanilla set up you might be quicker doing a backup, reinstall and restore.

No its not vanilla.. backup and restore doesnt change anything... This was the first steps to understand whats happeing.. its more complicate

 

[Saqqara]

I think you may have to contact 3CX support, to investigate the issue.

It would appear to be some corruption in the database, that requires fixing

 

[Avat]

I think you may have to contact 3CX support, to investigate the issue.

It would appear to be some corruption in the database, that requires fixing

yes this is the problem actually... we decided to kill the vm and reinstall again..

 

[JohnS_3CX]

Hope you used this guide when installing, mainly ensure you are using the 3CX ISO
https://www.3cx.com/docs/manual/installing-debian-linux-pbx/

 

[Avat]

Hope you used this guide when installing, mainly ensure you are using the 3CX ISO
https://www.3cx.com/docs/manual/installing-debian-linux-pbx/

The installation is on a Microsoft server 2016 edition not debian or linux

 

[JohnS_3CX]

My apologies, I did not notice.

If the issue is now resolved with the new VM, I will mark this as solved then.

 

[Avat]

My apologies, I did not notice.

If the issue is now resolved with the new VM, I will mark this as solved then.

Mostly yes but now we have a weird problem when we enable office hours does not understand it.
Ex office hours 0800-1700 (global settings) doesnt work, when passes 1700 works as normal !!!
This is very strange... Attached picture (Sip trunk conf) if office hours enabled the call doesnt go to ext 101 (we dont now were it goes exactly logs says)

11/20/2020 4:56:40 PM

6958468246

PBX

Not Answered

if office hours after 1700 goes to IVR correct....

 

[JohnS_3CX]

Since this is a Windows machine in a VM, you should check the following:

- Ensure Host server time is correct
- Ensure VM time is correct
- Ensure the VM timezone in Windows is correct
- Ensure the 3CX Timezone is correct in the management console
- Inbound Rules (if used) must also be set to Global Hours

 

[JohnS_3CX]

Also, we have not established that the office hours are bad.

We only established that extension 101 did not answer the call (if the above log is correct)

So make sure that the problem is not the extension 101. You can send the calls to another destination between 08:00 and 17:00 and see if the call arrives.

 

[Avat]

Since this is a Windows machine in a VM, you should check the following:

- Ensure Host server time is correct
- Ensure VM time is correct
- Ensure the VM timezone in Windows is correct
- Ensure the 3CX Timezone is correct in the management console
- Inbound Rules (if used) must also be set to Global Hours

all are correct also in logs sees that is correct.. The problem is when is in office hours the call goes to PBX !!! not to ext ..

 

[Avat]

Also, we have not established that the office hours are bad.

We only established that extension 101 did not answer the call (if the above log is correct)

So make sure that the problem is not the extension 101. You can send the calls to another destination between 08:00 and 17:00 and see if the call arrives.

Doesnt go anywhere... even we change the ext... like not understand the option...

 

[JohnS_3CX]

Hint: they can't go nowhere, they have to go somewhere and you need to find out where the line stops.

1. Go to the Activity Log page, and there you will find Settings on the top right.
2. Switch Logging to verbose from there
3. Press filter and "search by call" to see the last call made
4. Make a new call (which will fail like you say) and refresh the page
5. Filter now and you should see the call number has increased by 1
6. Select the last call there, and press ok
7. You can now start reading from the bottom, and go upwards to see the path that the call took, and find out where exactly your calls are going.

 

[JohnS_3CX]

At least from the point i see here, the call is rejected. There could be many reasons that the call gets rejected.

You need to look at the entire log for that specific filtered call. Start from the bottom and work your way up one message at a time.

 

[JohnS_3CX]

Also avoid posting it on the forum because I see some personal info here like your DID

 

[Avat]

Also avoid posting it on the forum because I see some personal info here like your DID

As you understand we are in dead end...we have tried everything...
When the office hours passes away it works fine....or if we delete office hours all works fine !!!!
We are hanging here...

 

[JohnS_3CX]

Like I said before, you need to look at the entire log for that specific filtered call.

Did you start from the bottom and work your way up one message at a time to better understand when the decision is made to reject the call?