Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: sbatsya on June 30, 2016, 08:36:32 AM
-
Hi,
Logs in phone system are reporting a database error. The exact log entry is below:
View: 38 ss4_asgt Tuples (Max): 756 (Current): 374
View: 39 ss4_line_data Tuples (Max): 71820 (Current): 16678
Read tuple error ***
Key is
2700353939322020201E000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00
Return Code is Failure
Tuple Number (one based) is 0
View: 40 ss4_line_info Tuples (Max): 756 (Current): 354
Could you please help and identify this error and what I would need to do to correct this?
-
Backup and restore. This is service affecting when you run the restore.
-
Hi,
Maybe you can do a DBMS CHECK FULL ?
From Mitel : http://edocs.mitel.com/UG/EN/MiCloud/2.0/Content/MiVB/DatabaseStatus.htm
-
Hi,
Maybe you can do a DBMS CHECK FULL ?
From Mitel : http://edocs.mitel.com/UG/EN/MiCloud/2.0/Content/MiVB/DatabaseStatus.htm
What he posted was from a DBMS checkfull.
Ralph
-
On a very, very, very rare occasion I've been able to find the error and delete it.
If I were chasing this, the first think I would do would be to export the Multiline Set Keys form to see if it stopped on a particular set.
If it did, I'd delete all the keys and re-run the DBMS check Full again.
Ralph
-
Hi All,
Thanks for the response.
I have curious to know why I have to give this command DBMS Check FULL, what is the purpose of this command and why I am getting this error.
-
I've never seen that command resolve anything.
As far as I know it's just a check to see if you have DB errors.
Ralph
-
How to resolve this issue,did we have any document to follow the steps.
Sent from my SM-A500G using Tapatalk
-
Look in the help files for these 2 things:
1) Data Save
then
2) Data Restore
Ralph
-
Thank you Ralph for your suggestion.
-
On a very, very, very rare occasion I've been able to find the error and delete it.
If I were chasing this, the first think I would do would be to export the Multiline Set Keys form to see if it stopped on a particular set.
If it did, I'd delete all the keys and re-run the DBMS check Full again.
Ralph
Hi, just to say I had the same problem and this solution did it for me!
For some reason the key #6 disappeared on one of our set (5360).
Thanks!!
-
I just had this happen to me this week, same issue!
One particular extension , 4435, skips the button from 9 to 11.
So, to clarify, erasing all the buttons on this set, then running a new DBMS FULL, "might" resolve this?
-
I just had this happen to me this week, same issue!
One particular extension , 4435, skips the button from 9 to 11.
So, to clarify, erasing all the buttons on this set, then running a new DBMS FULL, "might" resolve this?
My personal experience has been this does not work, it usually fails to delete because the data isn't returning the expected results... but it really won't hurt anything to try. Doing the backup and restore is more painless than you think though, and it will not restore corrupt data, but it won't give you an option either so anything that is corrupt will be skipped.
-
Odds are really good that the only way you're going to resolve this is to do a DB save/restore.
I have cleared similar errors before by deleting something but that was always the exception.
If you wanted to try something you could try deleting all the buttons on the phone and then the phone.
You're probably not going to be able to do that but you could try.
Here's some things you could try. (Backup 1st)
1) See if the buttons will load in the Multiline Key Form, then try to delete from there.
2) Export the extension's keys to a CSV file. Copy a button that has nothing assigned. Key type "Not Assigned" and then upload it.
3) I doubt any of the above will work so then do your save/restore.
Ralph
-
Well, we must have gotten lucky, then!
Here is what I discovered. The phone in question, just last week, before the Holiday, was converted from a 5304 to a 5330e. Basically, the customer just changed the phone type.
Somewhere in that process, the form must have gotten messed up, and then the error started showing up in the nightly DBMS audit.
So, my customer changed the phone BACK to a 5304 in the form. Then he cleared the keys. Ran the DBMS Check Full. No Errors.
Set the phone back to 5330e. Put the keys back in. Ran the Check Full again. No errors!
As I said, we got lucky! Here's to having a stress-free weekend! Yay!
-
That makes since. When converting to a smaller phone it will delete the other button records.
So it cleared the bad record.
Actually, that's a pretty nice solution to this type of problem that I hadn't thought of before.
Just change the phone type to a smaller phone and it will delete all the records above it.
Ralph