SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x2714

[Kryptonien]

PHP Driver version

• pdo_sqlsrv 5.3.0
• sqlsrv 5.3.0

SQL Server version

• Microsoft SQL Server 2008 R2 - 10.50.1600.1 (X64)

Client operating system

• Ubuntu 16.04.3

PHP version

• 7.2.1-1+ubuntu16.04.1

Microsoft ODBC Driver version

• Microsoft ODBC Driver 17 for SQL Server (libmsodbcsql-17.2.so.0.1)

Table schema

CREATE TABLE dbo.failed_jobs (
id BIGINT IDENTITY PRIMARY KEY,
connection NVARCHAR(MAX) NOT NULL,
queue NVARCHAR(MAX) NOT NULL,
payload NVARCHAR(MAX) NOT NULL,
exception NVARCHAR(MAX) NOT NULL,
failed_at DATETIME DEFAULT getdate() NOT NULL
) GO

Problem description

I randomly get the following errors:
SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x2714
SQLSTATE[08S02]: [Microsoft][ODBC Driver 17 for SQL Server]SMux Provider: Physical connection is not usable [xFFFFFFFF]

I tried several solutions I found but none of them seems to work, though it looks like there is an improvement:

1. https://social.msdn.microsoft.com/Forums/sqlserver/en-US/95fe26d2-2e6c-4c6b-b02d-10794e92dc7a/sqlstate-08s02-smux-provider-physical-connection-is-not-usable?forum=sqldataaccess (no difference)
2. Network timeout leads to full driver crash when using connection pooling: SMux Provider Physical connection is not usable  #762 which is related to PDO::ATTR_SERVER_VERSION not supported by driver #756 as mentioned (slight improvement I guess but still happening)
3. Turning Pooling option ON reduced the number of bug, strangely it's not recommended to put this on on Linux environment.

This is my unixODBC version

unixODBC 2.3.7
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/superviseur/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

By the way, I am not using the odbc.ini file as I am working with laravel PHP framework, which I presume create its own DSN string. I've followed the FAQ instructions by using the isql command and everything is fine.

I also checked the following compatibily documentation: https://docs.microsoft.com/en-us/sql/connect/php/system-requirements-for-the-php-sql-driver?view=sql-server-2017

If relevant:

• The servers are hosted on the same dedicated computer and both emulated on a virtual host.
• The error seem to always occur on the same table
• A complete example of a failing query from log: https://pastebin.com/s6p83xLF
  As you can see, on the first hand, the delete query is failing and return the infamous "TCP Provider: Error code 0x2714", then, the insert statement fails. (In the failed_jobs table)

I do not know what I can do more, I hope I can find some help here since it's been months I try to kill that bug. Ever since I upgraded from pdo_dblib to pdo_sqlsrv.

[david-puglielli]

@Kryptonien Thanks for providing this info. We will investigate. In the meantime, I suggest trying the following:

1. Turn MARS off and see if the problem persists. The SMux error may be related to MARS.
2. Keep connection pooling turned on. With the more recent unixODBC you are using, connection pooling should no longer be problematic.

[Kryptonien]

Thanks for replying, after some investigation I managed to find the way to add the MultipleActiveResultSets instruction to the DSN. I've read about this feature here.

One thing disturbe me in the source code of the Laravel Framework. In the microsoft documentation it's mentioned that this feature is disabled by default. The only option available with the Laravel Framework is "False" as per the following lines:

if (isset($config['multiple_active_result_sets']) && $config['multiple_active_result_sets'] === false) {
    $arguments['MultipleActiveResultSets'] = 'false';
}

The new DSN string looks like the following:
sqlsrv:Server=MyIP,1433;Database=DBName;MultipleActiveResultSets=false
which seems to be ok with this example

Anyway, I will keep you up to date, thanks for help.

[wuiler]

I have the same issue and same versions of pdo, sql, ubunt. However, the sqlserver is over a VPN y my problem reside executing and store procedure

[Kryptonien]

Hello,
The error is still happening unfortunately. With a little difference since I added the MultipleActiveResultSets=false instruction:
SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x2714
SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure

Might it be related to bug #809 ? The SqlServer could be overloaded ?

[wuiler]

No, it's not related to bug #809. I solve the problem moving to freetds. Im sorry but the driver is not yet mature.

[david-puglielli]

@Kryptonien As a similar problem was fixed very recently in unixODBC 2.3.7 and you say you have been trying to fix this for months, I have a feeling that you are still using an older version of unixODBC even though odbcinst -j says 2.3.7 (you would have had to install it manually and by default it installs into a different directory than the packaged unixODBC). Please run ldd on the msodbcsql driver and check which libodbcinst.so is being linked, and verify that it is the same as the one installed by unixODBC 2.3.7.

[Kryptonien]

Indeed, I followed the instructions from bug #762 to install it manually.

This is the result from ldd:

superviseur@php7:~$ ldd /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.2.so.0.1
        linux-vdso.so.1 =>  (0x00007ffe1f7f0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff652150000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff651f48000)
        libodbcinst.so.2 => /usr/local/lib/libodbcinst.so.2 (0x00007ff651d33000)
        libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff6518ef000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007ff65161d000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007ff6513d3000)
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff65116a000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff650f65000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff650be3000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff6508da000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff6506c4000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff6504a7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff6500dd000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff652775000)
        libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007ff64fed3000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007ff64fca4000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007ff64faa0000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007ff64f895000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007ff64f691000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff64f476000)

unixODBC 2.3.7 is installed in the "/usr/local/lib" folder. Furthermore, unixODBC 2.3.6 should be completely removed by these two commands, right ?

rm -f /usr/lib/x86_64-linux-gnu/libodbcinst.so*
rm -f /usr/lib/x86_64-linux-gnu/libodbc.so*

[david-puglielli]

Okay, then you have the correct unixODBC. How frequently does the error occur? Are you certain that it never occurs using sqlcmd or isql?

[david-puglielli]

I suggest trying something like this script.

[wuiler]

Yes I have the correct unixODBC installed (2.3.7). Thanks for your concern. However, We are going to test again on a clean server to make it work. Thanks to all again, and thanks @david-puglielli @Kryptonien

[Kryptonien]

@david-puglielli The error occur at least once a day.

It's always at 5am. There is a huge script running at that moment, that's why I was thinking of a server overload. Another huge script is suffering the same problem at midnight.

I will try your suggestion and see if I get the same result from isql at those hours.

[david-puglielli]

@Kryptonien Do you have any updates on this?

[Kryptonien]

@david-puglielli not yet sorry, I overwritten my test.log by mistake. I've been really busy lately and completely forgot until today. Since the error occur in the middle of the night I have to schedule the task and not forget afterward ... 👍

I've also done some other tests, and managed to fix the error from midnight, in my opinion it was due to a remanent failing network because I only restarted the php-fpm service.

One more thing, I said there was a huge script at 5am which is not true. It's only a loop with delete statements. Maybe optimizing this should fix the problem. It's more like a workaround than a fix ...

I scheduled a new test for this night, I'll try to not overwrite it this time !

[Kryptonien]

Turns out no error occur from the test script. The whole test.log is fine.
The error occured at:
timestamp | 1536375603 - 2018-09-08 05:00:03

The tests are every 5 seconds and both are successful:

samedi 8 septembre 2018, 05:00:01 (UTC+0200)
samedi 8 septembre 2018, 05:00:06 (UTC+0200)

Unless it's a really specific timed error, should i conclude there's no problem with the drivers ?

(The midnight error is happening again. The last one was at 2018-09-03 00:10, I restarted the php-fpm service. No error anymore and then this night at 2018-09-08 00:10, but I think it's not relevant.)

[david-puglielli]

It seems like there is some network problem, and I think you're right that the problem is not with our drivers. There are a couple of other things you could try to narrow down the issue - either an ODBC trace, or profiling with the SQL Server profiler. Running an ODBC trace will tell you what ODBC calls are being made, while the SQL Server profiler will tell you what's happening on the server side.

[yitam]

Closing this issue due to inactivity, @Kryptonien
Please feel free to reopen if you have other questions.

[Kryptonien]

Hello @david-puglielli ,

I have ODBC Trace enabled and I have done some tests with SqlServer Profiler. Unfortunately, that's not helping me much. Do you have any recommandation on how to configure Sql Server Profiler in my situation ? Which events should I check ?

I don't know what I should expect to find in the odbctrace.log. There's a bunch of calls, as you mentioned, all successfull.

I appreciate your help.

[david-puglielli]

For the profiler, I'd suggest checking any events related to errors/warnings and any related to connections (ie. everything under Sessions and everything under Errors and Warnings in the Trace Properties->Events Selection dialog). As for the ODBC trace, look for any connection related calls and see if anything looks unusual (you can attach it here as well and we can take a look).

[Kryptonien]

I've already tried those options, but I'll give it another shot just to be sure.

Here is the ODBC trace: https://pastebin.com/n88JtK3M
It's always the same bunch of calls.

[Kryptonien]

After several tests there's no error or whatsoever which would explain those "Communication link failure". The failing statements are not even showing on the Sql Server Profiler as if it wasn't reaching the server.

[david-puglielli]

The trace didn't reveal anything but it may be incomplete. You should be able to obtain a more complete trace by setting TraceOn and TraceFile in the connection options in your php script (in addition to the instructions in this link).

[Kryptonien]

I did not succeed to get a log file. I also did a raw test, to be sure if it wasn't a framework related problem:

$dsn = 'sqlsrv:Server=MyIP,1433;Database=DBName;TraceOn=true;TraceFile=/var/log/yolo.log';

$bdd = new PDO($dsn, 'myusername', 'mypassword') or die('Nop');
$q = $bdd->query('SELECT getdate()');
echo $q->fetchColumn();

This raw test does not output any log file. Is there anything wrong ?

[david-puglielli]

The log file and path from TraceFile must be identical to the one listed in odbcinst.ini. Also one more thing to try - remove the port number from the server name in the connection string and see if the problem still occurs.

[Kryptonien]

@david-puglielli Here is the new pastebin with some chunks of the log file: https://pastebin.com/im1p0yN0

Thank you for your time.

[david-puglielli]

The connection failures seem to happen only on calls to SQLExecute. Can you try cross-referencing the timestamps with the results of SQL Server profiling to see what the server is doing during these calls? The timestamps are located in the lines starting with [ODBC], in the third text field surrounded by [ ] (for example, in [ODBC][30571][1545124593.204343][SQLExecute.c][357] the timestamp is 1545124593.204343).

Here is something else to try - see if the SQL Server port is being used by another program, by running netstat -b on the server. If another program is using the port (1433 in your case) there's a chance it could cause network issues like the one you're seeing.

[Kryptonien]

Thanks, I'll do those checks.

I can already tell you that SQLServer is the only program using port 1433.

[Kryptonien]

Hi,

I think I figured it out. Looks like it's a timeout related issue as per this topic. I tried the workaround by increasing the timeout and it seems to have reduce the error to none (excluding periods of DB slowdowns I'm experiencing).

Is it an intended behavior, when a statement is hard killed by PHP, to close the connection ? (I'm assuming this is what's happening)

I'm pretty confident about the fact that this is not a Laravel related issue because the problem showed up at the moment I started using pdo_sqlsrv, but I could be wrong !

Looking forward to your feedbacks.

NB1: The intended behavior of my script is to throw a TimeoutException and store it to the failed_jobs table. It was working well back then as far as I remember.

NB2: Meanwhile, I'll do some more tests.

[yitam]

hi @Kryptonien @david-puglielli is not around till later next week, but glad to hear that you have seemingly figured out the real issue. As you probably know, there are multiple factors (this link gives you an idea) that can cause the connection timeout period to expire before the data source responds to the request, When that happens, the statement fails to be executed.

That being said, it doesn't look like the problem is ODBC driver or Laravel related. About your script that throws a TimeoutException, maybe things no longer work the same over time? Say, the existing databases / data tables / network need to be fine tuned? Let's see if @david-puglielli has any other idea when he comes back, and yes, please continue to explore and do some more tests, @Kryptonien

[Kryptonien]

It's ok, everyone needs to blow off someday ;) Plus, it's not like if I was in a hurry or something, my issue is kind of fixed. Thanks for letting me know anyway.

[mathieuk]

This seems rather similar to #885 .

@Kryptonien if your PHP process is receiving POSIX signals it will throw out the connection.

[Kryptonien]

@mathieuk I don't know anything about POSIX but by reading your ticket this looks similar enough to me.

Are you using Beanstalkd to process your jobs ? I was wondering if the issue could be kind of related to that. Since I can't reproduce the issue everytime it's hard to investigate.

I will look closely at your ticket to see the progress.

[mathieuk]

@Kryptonien it doesn't really matter what job driver you use. Laravel uses POSIX signals (namely, SIGALRM) to protect against run away jobs. I believe the default timeout is 60 seconds. If SIGALRM arrives (the timeout is hit) while your job is executing a MSSQL query you'll end up with the error messages you mentioned. If that's not your scenario, and you're not using signals in a different way, then maybe it isn't the same issue but I figured it seemed quite similar :)

[Kryptonien]

@mathieuk Yeah that's exactly what I thought. But I've done a bunch of tests in order to reproduce the issue repetitively, without success. In my case it's really random even though it shouldn't be.

[mathieuk]

@Kryptonien a bit of a stretch, but you might try and run a worker under strace and see if it's receiving signals before it dies. A quick search suggests running strace like: strace -e 'trace=!all' php artisan queue:work. You might see something like this:

$ strace -e 'trace=!all' php test-script.php
This is my test script 
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --
+++ exited with 0 +++

This shows my test script received SIGALRM. Perhaps you can rule out that situation that way.

[Kryptonien]

@mathieuk I noticed two cases:

1. When "--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---" is handled properly, there is "+++ killed by SIGKILL +++" in response and the worker (php artisan queue:work) end.

Strace

vagrant@dev:/var/www/e2$ strace -e 'trace=!all' php artisan queue:work --queue=default --timeout=10 --tries=1
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13324, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[2019-01-11 14:49:44] Processing: App\Jobs\CreateJob
Start!
Query!
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
+++ killed by SIGKILL +++
Killed

Error Log

[2019-01-11 14:49:54] local.ERROR: App\Jobs\CreateJob has been attempted too many times or run too long. The job may have previously timed out. {"exception":"[object] (Illuminate\\Queue\\MaxAttemptsExceededException(code: 0): App\\Jobs\\CreateJob has been attempted too many times or run too long. The job may have previously timed out. at /var/www/e2/vendor/laravel/framework/src/Illuminate/Queue/Worker.php:394)

---

2. When it's not handled properly, nothing happens, the worker is not killed and is doomed. Whenever a new Job arrives, it gets the link failure exception.

Strace

vagrant@dev:/var/www/e2$ strace -e 'trace=!all' php artisan queue:work --queue=default --timeout=10 --tries=1
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13120, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[2019-01-11 14:31:59] Processing: App\Jobs\CreateJob
Start !
Query !
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[2019-01-11 14:32:09] Failed:     App\Jobs\CreateJob
[2019-01-11 14:33:25] Processing: App\Jobs\CreateJob
Start !
Query !
[2019-01-11 14:33:25] Failed:     App\Jobs\CreateJob
[2019-01-11 14:34:08] Processing: App\Jobs\CreateJob
Start !
Query !
[2019-01-11 14:34:08] Failed:     App\Jobs\CreateJob
[2019-01-11 14:36:39] Processing: App\Jobs\CreateJob
Start !
Query !
[2019-01-11 14:36:39] Failed:     App\Jobs\CreateJob
[2019-01-11 14:48:30] Processing: App\Jobs\CreateJob
Start !
Query !
[2019-01-11 14:48:30] Failed:     App\Jobs\CreateJob

Error Log

[2019-01-11 14:32:09] local.ERROR: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure (SQL: insert into [failed_jobs] ([connection], [queue], [payload], [exception], [failed_at]) values (beanstalkd, default, {"displayName":"App\\Jobs\\CreateJob","job":"Illuminate\\Queue\\CallQueuedHandler@call","maxTries":null,"timeout":null,"timeoutAt":null,"data":{"commandName":"App\\Jobs\\CreateJob","command":"O:18:\"App\\Jobs\\CreateJob\":9:{s:29:\"\u0000App\\Jobs\\CreateJob\u0000className\";s:35:\"App\\Jobs\\CreatableJob\\GrosseRequete\";s:24:\"\u0000App\\Jobs\\CreateJob\u0000args\";a:0:{}s:6:\"\u0000*\u0000job\";N;s:10:\"connection\";N;s:5:\"queue\";N;s:15:\"chainConnection\";N;s:10:\"chainQueue\";N;s:5:\"delay\";N;s:7:\"chained\";a:0:{}}"}}, PDOException: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x2714 in /var/www/e2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:142
[2019-01-11 14:33:25] local.ERROR: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure (SQL: insert into [failed_jobs] ([connection], [queue], [payload], [exception], [failed_at]) values (beanstalkd, default, {"displayName":"App\\Jobs\\CreateJob","job":"Illuminate\\Queue\\CallQueuedHandler@call","maxTries":null,"timeout":null,"timeoutAt":null,"data":{"commandName":"App\\Jobs\\CreateJob","command":"O:18:\"App\\Jobs\\CreateJob\":9:{s:29:\"\u0000App\\Jobs\\CreateJob\u0000className\";s:35:\"App\\Jobs\\CreatableJob\\GrosseRequete\";s:24:\"\u0000App\\Jobs\\CreateJob\u0000args\";a:0:{}s:6:\"\u0000*\u0000job\";N;s:10:\"connection\";N;s:5:\"queue\";N;s:15:\"chainConnection\";N;s:10:\"chainQueue\";N;s:5:\"delay\";N;s:7:\"chained\";a:0:{}}"}}, PDOException: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure in /var/www/e2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:142

[david-puglielli]

@Kryptonien Is this still an issue? There are new releases of both the ODBC driver and SQLSRV drivers, please check if they fix your connection issues.

[lourdas]

Experiencing the same issue. I'm using 64-bit Ubuntu 18.04.2, with PHP 7.2 installed from the distro's repository. sqlcmd returns the same error too. The SQL Server is version 2005 (64-bit, exact version is 9.0.5000) running in Windows 2003 Server Enterprise.

Any ideas? Can we try something to further debug the issue?

[yitam]

@lourdas please note that we do not support SQL Server 2005, nor do we support Windows Server 2003 due to its lack of TLS 1.2 support. See related issue #657

[lourdas]

@yitam Thanks for letting me know. So, FreeTDS is the way to go I guess. Thanks!

[Kryptonien]

@Kryptonien Is this still an issue? There are new releases of both the ODBC driver and SQLSRV drivers, please check if they fix your connection issues.

Thanks for keeping me up to date, I will take a look at those new releases. 👍

[Kryptonien]

Still happening :)

PHP Driver version

pdo_sqlsrv 5.6.0+11812

Microsoft ODBC Driver version

libmsodbcsql-17.3.so.1.1

PHP version

7.2.16-1+ubuntu16.04.1+deb.sury.org+1

[nyg123]

I have encountered the same problem. Have you solved this problem now?

[yitam]

@nyg123 please elaborate the problem you've encountered and whether it is consistently reproducible. If so, please provide the repro scenario (scripts, drivers' versions, etc.)

[david-puglielli]

@Kryptonien @nyg123 The latest release of the ODBC driver, version 17.4, may fix the connection issues you're seeing. Please upgrade your msodbcsql17 install (instructions here).

[Kryptonien]

@david-puglielli Looks like I am unable to reproduce the problem with this new release. Though I have a fairly different environment than before. I'm now using Docker instead of Vagrant. I will try this new release in my production environment as soon as I can to ensure this is fixed.

Thank you.

[mathieuk]

I’m now depending on incoming signals throwing connection exceptions during query/fetching. So, does this version change signal handling or does it fix other connections issues?

…

Op 7 aug. 2019 om 20:24 heeft David Puglielli ***@***.***> het volgende geschreven: @Kryptonien @nyg123 The latest release of the ODBC driver, version 17.4, may fix the connection issues you're seeing. Please upgrade your msodbcsql17 install (instructions here). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[david-puglielli]

@Kryptonien You're welcome. Please let us know if the problem crops up again.

@mathieuk I don't know if the new version changes anything related to signal handling, but as indicated on issue #885, the signal handling issue is out of our scope and not something we can address. Please try the new driver and report any differences in behaviour from before. Meanwhile, we will continue to monitor progress on the PHP side.

[eduzetapy]

I had the same problem but I got to solve with this command
sudo setsebool -P httpd_can_network_connect 1
RedHat Linux comes with SELinux protection enabled by default.
It allows your web server to make its own network connections:
Try this, which allows your web server to make its own network connections

[yitam]

@Kryptonien we decided to close this issue due to inactivity. Please feel free to reopen if necessary.

[premsagar788]

Just removed DB_PORT and it worked like magic!

[maestro362]

where???

[bigfoot88]

sqlalchemy.exc.OperationalError: (pyodbc.OperationalError) ('08S01', '[08S01] [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x68 (104) (SQLExecDirectW)')

I have the same problem today because the length of the field is not enough relative to the length of the data. Lengthening the length of the field will solve the problem.