Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
3.2.2
-
None
Description
As MariaDB ODBC 3.1 reaches end of life, we have transitioned to version 3.2.2. Subsequently, most of our scripts began failing with the error "A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)"
The affected scripts are those migrating data from SQL Server to MariaDB via a linked server. The following insert operation fails when executed from SQL Server with a transport level error during the processing of multiple records in a loop, though it succeeds for a single record.
INSERT INTO MARIADEV.EpmMigrations..RefreshContentIntroduction (CourseId, Purpose, Notice, LegalNotice, LessonMapping, Copyright, Abstract, Objectives, Author, Test, Logo, CustomSectionXML, TransferDte, TransferBy, LoadStatus)
SELECT ContentId, Purpose, Notice, LegalNotice, LessonMapping, Copyright, Abstract, Objectives, Author, Test, Logo, CAST(CustomSectionXML as nvarchar(max)), GETUTCDATE(), @RunBy, 0
FROM MARIADEV.EpmMigrations..RefreshPartnerCourses c
INNER JOIN ContentMaster.dbo.ContentIntroduction i ON (i.ContentId = c.CourseCode OR i.ContentId = c.StandardsCourseCode)
WHERE c.StandardsCourseCode = @StandardsCourseCode;
Column data type details:
ContentMaster.dbo.ContentIntroduction - SQL Server table with all columns as NVARCHAR(MAX), except CustomSectionXML which is of type XML.
MARIADEV.EpmMigrations..RefreshContentIntroduction - MariaDB table with CourseId as VARCHAR(200), Purpose, Notice, LegalNotice, LessonMapping, Copyright, Abstract, Objectives, Author, Test as TEXT, Logo as VARCHAR(400), CustomSectionXML as LONGTEXT, TransferDte as DATETIME, TransferBy as VARCHAR(11), and Loadstatus as INT.
Could the issue be due to the driver's overhead when joining MariaDB and SQL Server tables with large data types?
Thank you for your report.
If it worked with 3.1, and fails with 3.2 - it's easy to suspect the regression in the driver. It's hard to understand what is going on in there. The best start would be if I could take a look at ODBC trace of that operation resulting in error. That would allow to see how your tool converts that query into ODBC API calls and hopefully where and why the error occurs.