airbyte
airbyte copied to clipboard
airbytehq
[source-MSSQL] incremental append failed due to `datetimeoffset` with CDC as update method
Connector Name
source-mssql
Connector Version
4.0.0
What step the error happened?
During the sync
Relevant information
I am doing a sync from an SQL Server to postgres DB.
Using incremental/append-deduped with CDC
The first sync itself is putting null values for my column LastModifiedDate which is of type datetimeoffset in MSSQL source.
2024-03-18 04:20:11 ERROR i.d.u.Loggings(logErrorAndTraceRecord):58 - Failed to properly convert data value for 'training.dbo.AssociatedEntities.LastModifiedDate' of type datetimeoffset 2024-03-18 04:20:11 source > java.time.format.DateTimeParseException: Text '2020-04-22 09:16:20.6566667 +00:00' could not be parsed at index 19
Note: It works for the values where the time is 00:00:00.0000000 +00:00.
Fails for: 2020-04-22 09:16:20.6566667 +00:00 But Works for: 2020-04-22 00:00:00.0000000 +00:00
Relevant log output
2024-03-18 04:20:11 ERROR i.d.u.Loggings(logErrorAndTraceRecord):58 - Failed to properly convert data value for 'training.dbo.AssociatedEntities.LastModifiedDate' of type datetimeoffset
2024-03-18 04:20:11 source > java.time.format.DateTimeParseException: Text '2020-04-22 09:16:20.6566667 +00:00' could not be parsed at index 19
2024-03-18 04:20:11 source > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052) ~[?:?]
2024-03-18 04:20:11 source > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1954) ~[?:?]
2024-03-18 04:20:11 source > at java.base/java.time.OffsetDateTime.parse(OffsetDateTime.java:404) ~[?:?]
2024-03-18 04:20:11 source > at io.airbyte.integrations.source.mssql.MssqlDebeziumConverter.lambda$registerDateTimeOffSet$4(MssqlDebeziumConverter.java:148) ~[io.airbyte.airbyte-integrations.connectors-source-mssql-0.50.45.jar:?]
2024-03-18 04:20:11 source > at io.debezium.relational.CustomConverterRegistry.lambda$getValueConverter$1(CustomConverterRegistry.java:147) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.TableSchemaBuilder.lambda$createValueGenerator$5(TableSchemaBuilder.java:281) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.TableSchema.valueFromColumnData(TableSchema.java:141) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.RelationalChangeRecordEmitter.emitReadRecord(RelationalChangeRecordEmitter.java:87) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.RelationalChangeRecordEmitter.emitChangeRecords(RelationalChangeRecordEmitter.java:50) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.pipeline.EventDispatcher.dispatchSnapshotEvent(EventDispatcher.java:207) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.RelationalSnapshotChangeEventSource.doCreateDataEventsForTable(RelationalSnapshotChangeEventSource.java:574) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at io.debezium.relational.RelationalSnapshotChangeEventSource.lambda$createDataEventsForTableCallable$6(RelationalSnapshotChangeEventSource.java:515) ~[debezium-core-2.4.0.Final.jar:2.4.0.Final]
2024-03-18 04:20:11 source > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
2024-03-18 04:20:11 source > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
2024-03-18 04:20:11 source > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
2024-03-18 04:20:11 source > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
2024-03-18 04:20:11 source > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
2024-03-18 04:20:11 source > at java.base/java.lang.Thread.run(Thread.java:833) [?:?]
Contribute
- [ ] Yes, I want to contribute
@rodireich mate can you please assist on this one too?
I tried to executed the java code MssqlDebeziumConverter.registerDateTimeOffset offline where it is failing, and it worked all right. Not sure if it is docker container local timezone issue or something else. Please advise.
@marcosmarxm Unfortunately, for now our intention is to deploy on kubernetes as going via cloud will open a whole lot of work to sort out vpc, network security, etc.
Would appreciate your thoughts on what can be done to get around this issue on airbyte running in container.
Like i said, the below code worked perfect on an online compiler:
import java.time.OffsetDateTime;
import java.time.format.DateTimeFormatter;
public class Main {
public static final DateTimeFormatter OFFSETDATETIME_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSSSSSS XXX");
private static final String DEBEZIUM_DATETIMEOFFSET_FORMAT = "yyyy-MM-dd HH:mm:ss[.][SSSSSSS] XXX";
public static void main(String[] args) {
DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern(DEBEZIUM_DATETIMEOFFSET_FORMAT);
String date = "2022-11-14 21:20:06.4466667 +00:00";
OffsetDateTime date1 = OffsetDateTime.parse(date.toString(), dateTimeFormatter);
System.out.println(date1);
System.out.println(toISO8601String(date1));
}
public static String toISO8601String(final OffsetDateTime date) {
return date.format(OFFSETDATETIME_FORMATTER);
}
}
Grooming:
- We will take a look, and either this is a specific mssql bug, or this is a bad value which will be handled by https://github.com/airbytehq/airbyte-internal-issues/issues/6504
- This likely an accuracy issue again (mili/nano seconds)
- learn more here https://learn.microsoft.com/en-us/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-ver16
Grooming:
- We will take a look, and either this is a specific mssql bug, or this is a bad value which will be handled by https://github.com/airbytehq/airbyte-internal-issues/issues/6504
Hi @evantahler @rodireich It appears that this GitHub issue is set to private. Could you please let me know when you expect this bug to be resolved?
@pankaj-lmg would be possible to you test using Airbyte Cloud? @marcosmarxm @rodireich I have tried to replicate data (mssql table to bigquery) through Airbyte cloud and Airbyte oss, I have observed that data is not populating for columns with type datetimeoffset. sample value: 2023-07-13 13:32:03.0490225 -04:00
Any updates on this issue? it is possible to tunning the mssql source kafka/debezium params? i tried to add some kafka/debezium params via the "jdbc params" option in mssql source connector but no results.
thanks!
Hi @Cir02, @pankaj-lmg, @sakent If I can please ask for a full log of the error. I have a theory on what is going on here, but I haven't been able to recreate this issue on my test environment. Thanks 🙏
Hi @Cir02, @pankaj-lmg, @sakent If I can please ask for a full log of the error. I have a theory on what is going on here, but I haven't been able to recreate this issue on my test environment. Thanks 🙏
I'm not seeing this error currently, however for datatimeoffset data type, sync from source MSSQL to bigquery destination is still failing with following error:
2024-05-16 00:30:23 [43mdestination[0m > ERROR type-and-dedupe i.a.i.b.d.t.TypeAndDedupeTransaction(executeTypeAndDedupe):48 Encountered Exception on unsafe SQL for stream dev_airbyte AnswerSet with suffix _airbyte_tmp, attempting with error handling com.google.cloud.bigquery.BigQueryException: Query error: Invalid timestamp: '2023-10-05 11:04:04.7681812 -04:00' at [2:1] at com.google.cloud.bigquery.Job.reload(Job.java:424) ~[google-cloud-bigquery-2.37.0.jar:2.37.0] at io.airbyte.integrations.destination.bigquery.typing_deduping.BigQueryDestinationHandler.execute(BigQueryDestinationHandler.java:146) ~[io.airbyte.airbyte-integrations.connectors-destination-bigquery.jar:?] at io.airbyte.integrations.base.destination.typing_deduping.TypeAndDedupeTransaction.executeTypeAndDedupe(TypeAndDedupeTransaction.kt:44) ~[airbyte-cdk-typing-deduping-0.35.0.jar:?] at io.airbyte.integrations.base.destination.typing_deduping.DefaultTyperDeduper.typeAndDedupeTask$lambda$5(DefaultTyperDeduper.kt:270) ~[airbyte-cdk-typing-deduping-0.35.0.jar:?] at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?] at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
Hi @Cir02, @pankaj-lmg, @sakent If I can please ask for a full log of the error. I have a theory on what is going on here, but I haven't been able to recreate this issue on my test environment. Thanks 🙏
sure, in my case was from mssql to postgres. and as you will see in the logs there are two types of errors, first cast error from datetimeoffset to string, where appliying only 'raw transformation' and second an error with lsn:
2024-05-13 07:42:45 [44msource[0m > INFO debezium-sqlserverconnector-GCH_DB-change-event-source-coordinator i.d.c.s.SqlServerStreamingChangeEventSource(lambda$executeIteration$0):290 Skipping change ChangeTableResultSet{changeTable=Capture instance "dbo_DC" [sourceTableId=GCH_DB.dbo.DC, changeTableId=GCH_DB.cdc.dbo_DC_CT, startLsn=0009bd47:00027c72:0003, changeTableObjectId=825079467, stopLsn=NULL], resultSet=SQLServerResultSet:25, completed=false, currentChangePosition=0009bd6b:00004ca5:0017(0009bd6b:00004ca5:0013)} as its order in the transaction 1 is smaller than or equal to the last recorded operation 0009bd6b:00004ca5:0017(0009bd6b:00004ca5:0013)[1]
2024-05-13 07:42:45 [44msource[0m > ERROR debezium-sqlserverconnector-GCH_DB-change-event-source-coordinator i.d.u.Loggings(logErrorAndTraceRecord):58 Failed to properly convert data value for 'GCH_DB.dbo.DC.Fecha' of type datetimeoffset java.time.format.DateTimeParseException: Text '2024-05-11 02:00:00.276489 +03:00' could not be parsed at index 20
at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2108) ~[?:?]
at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:2010) ~[?:?]
at java.base/java.time.OffsetDateTime.parse(OffsetDateTime.java:405) ~[?:?]
at io.airbyte.integrations.source.mssql.MssqlDebeziumConverter.lambda$registerDateTimeOffSet$4(MssqlDebeziumConverter.java:156) ~[io.airbyte.airbyte-integrations.connectors-source-mssql.jar:?]
at io.debezium.relational.CustomConverterRegistry.lambda$getValueConverter$1(CustomConverterRegistry.java:147) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.TableSchemaBuilder.lambda$createValueGenerator$5(TableSchemaBuilder.java:297) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.TableSchema.valueFromColumnData(TableSchema.java:141) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalChangeRecordEmitter.emitCreateRecord(RelationalChangeRecordEmitter.java:71) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalChangeRecordEmitter.emitChangeRecords(RelationalChangeRecordEmitter.java:47) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.pipeline.EventDispatcher.dispatchDataChangeEvent(EventDispatcher.java:271) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource.lambda$executeIteration$0(SqlServerStreamingChangeEventSource.java:334) ~[debezium-connector-sqlserver-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.jdbc.JdbcConnection.prepareQuery(JdbcConnection.java:596) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.connector.sqlserver.SqlServerConnection.getChangesForTables(SqlServerConnection.java:385) ~[debezium-connector-sqlserver-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource.executeIteration(SqlServerStreamingChangeEventSource.java:235) ~[debezium-connector-sqlserver-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource.executeIteration(SqlServerStreamingChangeEventSource.java:67) ~[debezium-connector-sqlserver-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.connector.sqlserver.SqlServerChangeEventSourceCoordinator.executeChangeEventSources(SqlServerChangeEventSourceCoordinator.java:117) ~[debezium-connector-sqlserver-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:140) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
maybe its also part of the problem, for that reason, add the params for tunning kafka/deebzium inside the mssql docker container can resolve this kind of issues.
thks! airbyte_0.50.30_mssql_4.0.20_postgres_0.4.0.txt
Thanks for the log @Cir02 . I've been trying to repro this and was unable. We recently updated the JDBC driver we use with mssql to the latest one, and also the version of debezium library used for CDC. Do you mind trying with the latest source mssql 4.0.23 and see if problem still persists?
From your log I see that the value causing this error (2024-05-10 19:00:01.604805 +03:00) only has 6 digits of precision: 604805, while our conversion is expecting the default 7 digits.
Can you confirm that in your table the offending column GCH_DB.dbo.DC.Fecha is of type DATETIMEOFFSET(6)?
Actually, I see that pasting the problem value above (2024-05-10 19:00:01.604805 +03:00) even into the default DATETIMEOFFSET(7) causes this problem.
add the params for tunning kafka/deebzium inside the mssql docker container can resolve this kind of issues
To what Kafka param do you refer?
From your log I see that the value causing this error (
2024-05-10 19:00:01.604805 +03:00) only has 6 digits of precision: 604805, while our conversion is expecting the default 7 digits.Can you confirm that in your table the offending column GCH_DB.dbo.DC.Fecha is of type
DATETIMEOFFSET(6)?
is type DATETIMEOFFSET(7) GCH_DB.dbo.DC.Fecha
What's odd is that this issue was opened with an error indicating a failure to convert a value with 7 precision digits (2020-04-22 09:16:20.6566667 +00:00).
What's odd is that this issue was opened with an error indicating a failure to convert a value with 7 precision digits (
2020-04-22 09:16:20.6566667 +00:00).
i can confirm in the source database (mssql) all datetimeoffset are type DATETIMEOFFSET(7), as you can see in the logs is like airbyte/source is trimming the value in one decimal.
Actually, I see that pasting the problem value above (2024-05-10 19:00:01.604805 +03:00) even into the default DATETIMEOFFSET(7) causes this problem.
add the params for tunning kafka/deebzium inside the mssql docker container can resolve this kind of issues
To what Kafka param do you refer?
I refer to the posibility of tunning kafka/dbz configuration inside this source, i.e, change snapshot.mode, value.converter and key,conveter etc... it could be possible to add optional propieties as the 'jdbc params'?
thx!!
Thanks for the log @Cir02 . I've been trying to repro this and was unable. We recently updated the JDBC driver we use with mssql to the latest one, and also the version of debezium library used for CDC. Do you mind trying with the latest source mssql 4.0.23 and see if problem still persists?
same problem with version 4.0.23:
2024-05-17 09:43:32 source > ERROR pool-6-thread-1 i.d.u.Loggings(logErrorAndTraceRecord):58 Failed to properly convert data value for 'GCH_DB.dbo.DC.Fecha' of type datetimeoffset java.time.format.DateTimeParseException: Text '2024-01-01 00:00:00.773412 -03:00' could not be parsed at index 20
at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2108) ~[?:?]
at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:2010) ~[?:?]
at java.base/java.time.OffsetDateTime.parse(OffsetDateTime.java:405) ~[?:?]
at io.airbyte.integrations.source.mssql.MssqlDebeziumConverter.lambda$registerDateTimeOffSet$4(MssqlDebeziumConverter.java:156) ~[io.airbyte.airbyte-integrations.connectors-source-mssql.jar:?]
at io.debezium.relational.CustomConverterRegistry.lambda$getValueConverter$1(CustomConverterRegistry.java:147) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.TableSchemaBuilder.lambda$createValueGenerator$5(TableSchemaBuilder.java:297) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.TableSchema.valueFromColumnData(TableSchema.java:141) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalChangeRecordEmitter.emitReadRecord(RelationalChangeRecordEmitter.java:87) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalChangeRecordEmitter.emitChangeRecords(RelationalChangeRecordEmitter.java:50) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.pipeline.EventDispatcher.dispatchSnapshotEvent(EventDispatcher.java:214) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalSnapshotChangeEventSource.doCreateDataEventsForTable(RelationalSnapshotChangeEventSource.java:625) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at io.debezium.relational.RelationalSnapshotChangeEventSource.lambda$createDataEventsForTableCallable$7(RelationalSnapshotChangeEventSource.java:559) ~[debezium-core-2.6.1.Final.jar:2.6.1.Final]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
any ideas?
thx!
hello there!
in our company have found the posible cause of the issue.
in our case, some records with type DATETIMEOFFSET(7) were causing the parse exception 'java.time.format.DateTimeParseException'. All of these date have the nanoseconds part ends in 0, i.e: “2024-05-10 16:00:01.6048050 +03:00”.
When retrieving the records from the database with the mssql jdbc conector, the class microsoft.sql.DateTimeOffset from the conector truncate the 0 and we get a date like this: “2024-05-10 16:00:01.604805 +03:00” when transform to DateTimeOffset object.
So, as a result, when the code try to parse DateTimeOffset object to OffsetDateTime object, fails because the truncate date not match with the pattern DEBEZIUM_DATETIMEOFFSET_FORMAT = "yyyy-MM-dd HH:mm:ss[.][SSSSSSSSS] XXX" . This parse is locate in airbyte-integrations/connectors/source-mssql/src/main/java/io/airbyte/integrations/source/mssql/MssqlDebeziumConverter.java:
private void registerDateTimeOffSet(final RelationalColumn field,
final ConverterRegistration<SchemaBuilder> registration) {
registration.register(SchemaBuilder.string(), input -> {
if (Objects.isNull(input)) {
return DebeziumConverterUtils.convertDefaultValue(field);
}
if (input instanceof DateTimeOffset) {
return DataTypeUtils.toISO8601String(
OffsetDateTime.parse(input.toString(),
DateTimeFormatter.ofPattern(DEBEZIUM_DATETIMEOFFSET_FORMAT)));
}
LOGGER.warn("Uncovered DateTimeOffSet class type '{}'. Use default converter",
input.getClass().getName());
return input.toString();
});
}
Our solution is to detect if the date have only 6 nanoseonds add the missing zeros so that the DateTimeFormatter parsing does not fail. As i have said before, we have only found this error if the 7th nanosecond of DATETIMEOFFSET(7) is a 0, not found with other numbers.
private void registerDateTimeOffSet(final RelationalColumn field,
final ConverterRegistration<SchemaBuilder> registration) {
registration.register(SchemaBuilder.string(), input -> {
if (Objects.isNull(input)) {
return DebeziumConverterUtils.convertDefaultValue(field);
}
if (input instanceof DateTimeOffset) {
try{
return DataTypeUtils.toISO8601String(
OffsetDateTime.parse(input.toString(),
DateTimeFormatter.ofPattern(DEBEZIUM_DATETIMEOFFSET_FORMAT)));
}catch (Exception e){
String[] inputSplit = input.toString().split(" ");
String[] hours = inputSplit[1].split("\\.");
inputSplit[1] = String.join(".", hours[0], String.format("%-7s", hours[1]).replace(' ', '0'));
String inputStr = String.join(" ", inputSplit);
return DataTypeUtils.toISO8601String(OffsetDateTime.parse(inputStr, DateTimeFormatter.ofPattern(DEBEZIUM_DATETIMEOFFSET_FORMAT)));
}
}
LOGGER.warn("Uncovered DateTimeOffSet class type '{}'. Use default converter",
input.getClass().getName());
return input.toString();
});
}
We can confirm, that this code solve in our case the issue. However it would be better to check the mssql jdbc lib and check this problem if the microsoft.sql.DateTimeOffset object trim DATETIMEOFFSET(7) dates .
Can you replicate the error again @rodireich and see is this can be a valid solution?
thx!
Amazing investigation @Cir02! Yes I believe you found the root cause here, and a possible solution.
What I will try to do is to see if we can get rid of the assumption that the converted value has 7 digits precision, as it it clearly incorrect. even if the column is defined as DATETIMEOFFSET(7). Many thanks for the extra leg work. I really appreciate it! 👋
Please try out the latest version of the connector we just released (https://github.com/airbytehq/airbyte/pull/39342) and let us know if that fixes things
Thanks heaps. Logs are super clean now, with no warning or errors. Tried with 4.0.28 version of connectors/source-mssql.
Thanks again for help.