ASTVDauto screen is missing only Screen -r

[PJ111288]

Hi Guys,

Please help on this "ASTVDauto screen is missing only. I debugged it and found below results. I am newbie so i am unable to understand what is meaning of this error and why this is happened and how can i fix it?



[root@AS]# /usr/share/astguiclient/AST_VDauto_dial.pl --debugX
TIME DEBUG: ||0| GMT: 15:13
2020-06-27 15:13:05|LOGGED INTO MYSQL SERVER ON 1 CONNECTION||
TIME DEBUG: -5.00|-5.00|0| GMT: 20:13
2020-06-27 15:13:05|SERVER CALLS PER SECOND MAXIMUM SET TO: 500 |25||
2020-06-27 15:13:05|LIVE AGENTS LOGGED IN: 28 ACTIVE CALLS: 0|
2020-06-27 15:13:05|PSBLAST 209.85.122.173: agents: 10 (READY: 10) dial_level: 0 (10|0|0) |
2020-06-27 15:13:05|PSBLAST 209.85.122.173: Calls to place: 0 (0 - 0 [0 + 0||]) 0 |
2020-06-27 15:13:05|CAMPAIGN DIFFERENTIAL: 10 10 (10 - 0)|
2020-06-27 15:13:05|LOCAL TRUNK SHORTAGE: 0|0 (0 - 500)|
2020-06-27 15:13:05|55555555 209.85.122.173: agents: 10 (READY: 10) dial_level: 0 (10|0|0) |
2020-06-27 15:13:05|55555555 209.85.122.173: Calls to place: 0 (0 - 0 [0 + 0||]) 0 |
2020-06-27 15:13:05|CAMPAIGN DIFFERENTIAL: 10 10 (10 - 0)|
2020-06-27 15:13:05|LOCAL TRUNK SHORTAGE: 0|0 (0 - 500)|
2020-06-27 15:13:05|32344444 209.85.122.173: agents: 8 (READY: dial_level: 0 (8|0|0) |
2020-06-27 15:13:05|32344444 209.85.122.173: Calls to place: 0 (0 - 0 [0 + 0||]) 0 |
2020-06-27 15:13:05|CAMPAIGN DIFFERENTIAL: 8 8 (8 - 0)|
2020-06-27 15:13:05|LOCAL TRUNK SHORTAGE: 0|0 (0 - 500)|
2020-06-27 15:13:05|PSBLAST 209.85.122.173: CALLING|
2020-06-27 15:13:05|55555555 209.85.122.173: CALLING|
2020-06-27 15:13:05|32344444 209.85.122.173: CALLING|
TIME DEBUG: -5.00|-5.00|0| GMT: 20:13
2020-06-27 15:13:05|| logindate UPDATED 0E0|'PSBLAST','55555555','32344444'||
TIME DEBUG: -5.00|-5.00|0| GMT: 20:13
DBD::mysql::st execute failed: Unknown column 'na_call_url' in 'where clause' at /usr/share/astguiclient/AST_VDauto_dial.pl line 2772.
executing: SELECT count(*) FROM vicidial_lists where na_call_url IS NOT NULL and na_call_url!='' and list_lastcalldate > "2020-06-27 09:13:05"; Unknown column 'na_call_url' in 'where clause' at /usr/share/astguiclient/AST_VDauto_dial.pl line 2772.
You have mail in /var/spool/mail/root

Many Thanks.

[carpenox]

You have multiple servers? To get it rubbing you can run perl install.pl in the trunk folder

[PJ111288]

Hey Carpenox,

The Saviour...

Yes i have multiple server but this standalone server. I try and let you know.

Many Thanks.

[PJ111288]

No luck. Still ASTVDauto screen is missing only Screen -r and only these socket are coming

screen -ls
There are screens on:
2621.astshell20200627161224 (Detached)
2843.ASTlisten (Detached)
2840.ASTsend (Detached)
2859.ASTVDadapt (Detached)
2837.ASTupdate (Detached)
2626.asterisk (Detached)
2895.ASTconf3way (Detached)
2878.ASTfastlog (Detached)
2855.ASTVDremote (Detached)
9 Sockets in /var/run/screen/S-root.

[williamconley]

Code: Select all

Unknown column 'na_call_url' in 'where clause' at /usr/share/astguiclient/AST_VDauto_dial.pl line 2772.

This indicates a DB schema mismatch. If you upgraded, you forgot to upgrade the DB to match OR your db upgrade failed and you didn't resolve the issue and properly complete the upgrade.

If this is a fresh install, start over. This should never happen on a fresh install and this would be indicative of something having gone horribly awry.

[PJ111288]

Hello Williamconley,

Thanks a lot.

Neither it is fresh install nor upgraded. This is production server which was running fine till yesterday but suddenly i noticed that on Real time Report screen No Leads on hopper but in campaign Data is showing.

Many Thanks.

[williamconley]

There is an impossibility in play. Code has been changed to "expect" that field OR that field has been deleted when it was once there or that script has never actually run OR the server configuration has been altered in such a way that this line of the autodial script is now firing when it previously did not.

Happy Hunting!

[PJ111288]

Hi William,

i did dig more and found that below columns are missing in vicidial_lists table. Could you please advise on this?


| na_call_url | text | YES | | NULL | |
| local_call_time | varchar(10) | NO | | campaign | |
| web_form_address_three | text | YES | | NULL | |
| status_group_id | varchar(20) | YES | | | |
| user_new_lead_limit | smallint(5) | YES | | -1 | |
+-----------------------------+-----------------------------------------------------------------------------------+------+-----+-----------------------+-------+
27 rows in set (0.00 sec)

[williamconley]

missing is an interesting description. you could restore a previous backup set (to a DB other than asterisk to avoid damage) and see if those fields WERE present. if you are using the stock vicidial backup, you can also check the backup copy of the autodial script and see if it's been changed.

Possibilities
* Code has been changed to "expect" that field
* that field has been deleted when it was once there
* that script has never actually run
* the server configuration has been altered in such a way that this line of the autodial script is now firing when it previously did not

As a "duct tape" measure, you could (make a backup copy and) change the line noted to remove the field in question. But that field will then be loaded into a variable, so you would then need to delete the creation and use of that variable OR just change the sql code to '' as fieldname (for each) so it would be there, have the same name, and be empty to avoid errors.

Code: Select all

'' as fieldname

I will note, however, that this really does look like an upgrade. have you run "perl install.pl"? If so, that was the problem ... downgrade the scripts or upgrade the DB.

[carpenox]

mysql -p -f --database=asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql

[PJ111288]

missing is an interesting description. you could restore a previous backup set (to a DB other than asterisk to avoid damage) and see if those fields WERE present. if you are using the stock vicidial backup, you can also check the backup copy of the autodial script and see if it's been changed.

Possibilities
* Code has been changed to "expect" that field
* that field has been deleted when it was once there
* that script has never actually run
* the server configuration has been altered in such a way that this line of the autodial script is now firing when it previously did not

As a "duct tape" measure, you could (make a backup copy and) change the line noted to remove the field in question. But that field will then be loaded into a variable, so you would then need to delete the creation and use of that variable OR just change the sql code to '' as fieldname (for each) so it would be there, have the same name, and be empty to avoid errors.

Code: Select all

'' as fieldname

I will note, however, that this really does look like an upgrade. have you run "perl install.pl"? If so, that was the problem ... downgrade the scripts or upgrade the DB.

Thanks a lot William for you time and help. if i do the same version backup and reinstall astguiclient with current version so will it work?

[PJ111288]

mysql -p -f --database=asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql

Hi carpenox,

Thanks for this but i cant upgrade because i have not done this before and its production server so i am scare to loose data of my customers and i cant take risk right now.

If anything else you can advise so please tell.

Many Thanks.

[carpenox]

if you go to system settings in admin, does it say anything about wrong DB schema?

[williamconley]

Best advice: full backup ... then upgrade. if it fails you can still revert. if it doesn't, you're likely "up" with very little effort.

note that upgrading the db requires running all the commands on the upgrade sql file that have NOT already run. we like to find the db_schema update command that matches the present db_schema (visible admin system settings) and delete all the lines above it (since they have obviously already run). then the rest of the commands should not have an error. if you run the commands that have already run, often there's a conflict (attempting to create an index that already exists, for instance, can stop the script from running).

[PJ111288]

Best advice: full backup ... then upgrade. if it fails you can still revert. if it doesn't, you're likely "up" with very little effort.

note that upgrading the db requires running all the commands on the upgrade sql file that have NOT already run. we like to find the db_schema update command that matches the present db_schema (visible admin system settings) and delete all the lines above it (since they have obviously already run). then the rest of the commands should not have an error. if you run the commands that have already run, often there's a conflict (attempting to create an index that already exists, for instance, can stop the script from running).

Hi William,

Thanks a lot for your guidance and educating me.

I am able to fixed this issue by reverting the astguiclient version because i found astguiclient version in admin system settings 2.9rc1 but in file /usr/src/astguiclient/version is 2.11rc1 so i revert it to 2.9rc1.

I ll try to upgarde version in my testing server which you advise so that i can learn it as well.

Many Thanks for you time and effort. Really appreciated and very kind gesture.

[PJ111288]

if you go to system settings in admin, does it say anything about wrong DB schema?

Hi carpenox,

There was no error but i found the exact issue which i mentioned on William reply. Thanks you very much for your time and help.

Many Thanks.

[carpenox]

pj,

glad 2 hear it. yes bill is one of the best for sure.

nox

[williamconley]

Beware of the version in system settings. To be absolutely certain to version match:

SVN is used to manage the "install directory" (/usr/src/astguiclient/trunk)

The install directory has a group of sql files that are used to upgrade from the first version to NOW (based on the svn revision level presently in THAT directory).

When your last sql upgrade file has a last line indicating that the db schema value should be what is presently shown in your System Settings ... you have a match. All your code will match your entire DB if you run install.pl with that version loaded.

Anything else is more of a "sort of" match. That's the only truly reliable method. How you get there is a matter of experience and knowledge of svn. But upgrading/downgrading that svn repository until you get lucky and it matches is the easiest amateur way to get a lock-on match of your present db schema.

start here:

Code: Select all

tail /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql | grep db_schema_version
mysql -u cron -p1234 asterisk -e "select * from system_settings\G" | grep schema
cd /usr/src/astguiclient/trunk
svn info | grep Revision


Compare the db schema in system settings to the db schema in the upgrade.sql file.
Note the svn revision level.
Increase or decrease the svn revision level with "svn up -r ####" and ... try again until the db schema in the sql file and system settings match. Example:

Code: Select all

svn up -r 2946

Then run perl install.pl. Example:

Code: Select all

cd /usr/src/astguiclient/trunk
perl install.pl --copy_sample_conf_files

Note that --copy_sample_conf_files will overwrite the .conf files presently in the system. Any that you have edited will need to be re-edited. Such as externip=xxx.xx.xx.x in sip.conf. While updating these isn't always necessary, NOT updating them has been known to blow an entire workday for simple "missed" change that's very difficult to find otherwise. Skip copy_sample_conf_files at your own risk.

Vicidial Version to DB Schema

[PJ111288]

Hi William,

Thanks a lot for this information you shared about the upgrading or downgrading SVN and DB schema matching.

I ll sure take care about this.

Many Thanks.
PJ111288