msaccess-vcs-addin
msaccess-vcs-addin copied to clipboard
joyfullservice
4.1: exporting table data with binary content
I get an error when a table that has binary content in a LONG TEXT field gets exported and as well when imported. It's the table tbl_cal_binary of the amvCalendar
Do you mean this message:
Unable to parse the XML for file ''. This may be due to containing malformed XML. Check the source XML document for validity. In some cases, this may be due to table data containing characters not allowed in XML documents.
The problem starts here:
clsDbTableData.IDbComponent_Export
Application.ExportXML acExportTable, m_Table.Name, strFile, , , , , acEmbedSchema
The message comes from:
With New clsSourceParser
.LoadSourceFile strFile
WriteFile .Sanitize(ectXML), strFile
End With
In my opinion, however, the problem occurs because the data field type (LongText instead of LongBinary) selected for binary data is suboptimal.
yes, that's what I meant. I agree, that the field type is not set adequate,but still, it's some weird error that may be handled - or we agree (again), that the data is actually bad and needs to be treated manually.
Actually I think it's a larger problem: I notice, that the export continues - ok But, when I press "Export Source Files" again, directly after the export has finished, the table data get's exported again - at least the statusbar output makes me think so. In the log I can see, that the tables are being sanitized.
Just to add to the previous post. The error in the log looks like this:
Exporting table data...
TBL_CAL_BINARYERROR: Unable to parse the XML for file ''. This may be due to containing malformed XML. Check the source XML document for validity. In some cases, this may be due to table data containing characters not allowed in XML documents. Source: clsSourceParser.SanitizeXML
ERROR: Error exporting table data for TBL_CAL_BINARY Error 3001: Die Argumente sind vom falschen Typ, liegen außerhalb des Gültigkeitsbereiches oder sind miteinander unvereinbar. Source: clsDbTableData.Export
Binary data in LongText:
The issue is that the Access method Application.ExportXML does not export the data correctly/as expected.
We don't really have a good way to determine if data in a table has changed, so an export will always export table data for any tables set to export data. It is the expected behavior that the table data would export each time.
I generally encourage users to export table data for things like configuration settings that are critical for the base functionality of the application. This add-in isn't really intended to be a backup solution for the data itself. That is probably better handled using other tools more suited for that purpose.
Binary data in LongText: The issue is that the Access method Application.ExportXML does not export the data correctly.
Based on this feedback from @josef-poetzl, it sound like this might be a limitation in Microsoft Access and not something we can easily fix through the add-in. (Other than recommending that the data type be changed in the underlying table.)
Perhaps one approach would be to trap the error and check the table for this specific data type so we can present a more helpful recommendation in the log file.
Trapping the error would be good. I expect this not to happen very often, so most users will never see it.Bit if a users sees it it will be more informative than it currently is.