SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2147483647'

Upon fwconsole reload I am getting the error SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘2147483647’ and can’t Apply Config from the GUI. I have traced the problem to the table digium_phones_devices which is the only index greater than or equal to the number shown in the error.
Here is the output of the 2 highest entries in the table.

MariaDB [asterisk]> select * from digium_phones_devices where id>=‘100000’;
±-----------±--------------+
| id | name |
±-----------±--------------+
| 908888 | Zulu Test |
| 2147483647 | UserName Changed |
±-----------±--------------+

/etc/asterisk/res_digium_phone_devices.conf has an entry
[2147483647]
type=phone
full_name=Username Changed

Can I just change the number in brackets above to something like 910000 and reload?

Thanks in advance…

your issue relates to max int so yes use a number below 2,147,483,647

Yes I realized the number is the maximum maria can handle … so I tried removing the first 2 digits of the number in the config file and the table, when I do a fwconsole reload -vv I stll get the error, maybe it is specified in another table as a non index value or a file which writes to this table? Any ideas how to fix it …
Thanks

I dumped the asterisk and askeriskcdrdb databases to a file and found quite a few matching values in tables.

digium_phones_device_phonebooks
digium_phones_device_settings
digium_phones_devices
digium_phones_lines
endpoint_basefiles
freepbx_settings interesting there is a note there: For unlimited clear this box and save.
I wonder if I can reset the max or if that is a maria limit

John

you shouldn’t be dividing by 100 (removing first two digits) you could try dividing by any power of two perhaps 128 ?

echo $(( 2147483647 /128))
16777215

I wouldn’t think the number used matters as long as it isn’t over the limit and not used by any other digium id. Looks like there are multiple entries in the database in the other files many in digium phones settings since each settings is in a row. I could manually go in and change all these, simplest way to make it higher than the last used but much lower is take off the first 2 digits for all entries.

But isn’t there a better fix, something at a higher level where I can reset the entry from the GUI or a file which writes the database, fwconsole reload I thought reloads some things from files. Or from the GUI remove and restore the user, I don’t want to have to reconfigure the users phone … maybe make a new extension with the and move the inbound route and copy the secret … would that delete the bad entry?

I would stop using zulu, it’s pretty well unsupported now so also probably pretty well unfix-able.

Okay looks like we don’t have a license for zulu or sangoma connect, Tried to disable the zulu module and it says sangoma cmr depends on it … What do you think? disable sangoma_connect and zulu?

Sorry, I don’t/can’t use any commercial modules. But if you don’t have use of them , fwconsole ma delete . . . (not disable) them

disabled both from the command line and reload still generates the error

edited post, delete not disable

Well I change the file in /etc/asterisk/res_digium_devices.conf
And changed the database in
digium_phones_device_phonebooks
digium_phones_device_settings
digium_phones_devices
digium_phones_lines

fwconsole reload, same error and the database and file is restored to the old value

If you have any Digium phones, they now get support only from Sangoma, I would go there for support.

So to clarify that is max int. That means ALL 11 digit phonenumbers and most 10 digit phone numbers will be changed to 2147483647 because it is the largest number. The column type could be changed to support bigint to allow larger numbers but that is unlikely to change as the module isn’t used any more officially.
The digium_phones module is deprecated and the functionality was moved in to the commercial endpoint manager.

Basically you can only use a 10 digit number for area codes 200-213 and a limited part of 214. Long story short don’t use phone numbers.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.