When adding a new row to a table with retrieved columns, the value of the Request Data column is being truncated. We believe that the actual message data that gets put into the Request Data parameter and database field for these message has exceeded the size limit.
In the database cell editor it shows the message size is 65535 bytes. MySQL documentation states that text data type has a max length of 65535.
The parameter Request Data is just a string saved parameter with length Type = "next param".
DataMiner is a 9.6 with a MySQL database.
Is the limit of a string parameter in a table equals 65535 bytes?
if not, what determines the limit in this case?
Or is it always going to find memory no matter how big the string is and the problem might be somewhere else?
Please and thank you!
The parameter/data in question is internally generated by Dataminer protocol code, it is not received from an actual device. The data point/table based parameter is used to pass messaged between different elements in Dataminer and the table is a saved parameter so unprocessed messages are retained across a system restart. In this case the protocol in question is creating a message that exceeds the size limit of the MySQL database table field type and when the protocol reads the message from the database it is no longer a valid message due to it being truncated by MySQL.
The actual data limit is indeed here the database field. Since on MySQL it is of type TEXT the size comes down to 65535 bytes.
Some notes depending if your protocol is flagged as a unicode protocol the amount stored will be halved.
DataMiner itself normally doesn’t truncate, you could mark the table as volatile and remove the save option to verify it’s not data from the database but run-time data polled from the device. I’m not sure where you double check if this data is truncated? The data in the streamviewer will for instance be displayed as truncated with … but the parameter will actually contain the entire response.