sqlsrv_connect does not try to establish a connection when there is no instance specified #1514
Comments
|
Can you provide ODBC trace? Hopefully it'll have something more helpful there to explain what error is actually happening |
|
Yes of course: I omitted the first ~600 lines of calls to Full ODBC trace |
|
Thank you, I'm looking through it now. One more question: what version of unixODBC is on this machine? |
|
Thanks to you, too! The unixODBC version is 2.3.12 |
|
Not too sure why it's not giving a proper error yet, but can I see ODBC trace for the successful case (sqlcmd)? It must be doing something different if the connection works there. |
|
Yes, surely. This is the trace when running sqlcmd: |
|
Hey @v-makouz, could you find anything that might be a hint to the problem's root? Or any idea what I might try to get there? |
|
I wasn't able to reproduce this yet, but one more thing to try is to |
|
Okay, today I managed to run both commands with TBH, analysing these kind of log files feels a little bit like stumbling in the dark for me, but if I'm not mistaken in the screenshot below is the moment both versions start their connection to the server.
The left one is the successful connection with Both commands read some random bytes from From this, I can't really tell what the problem might be. If you have anything, I'd be glad to hear... |
|
Thanks, I'll see if I can figure anything from the screenshot. Any chance I can get these as text files? It would make it easier to search through. The option for a file output is |
|
Yes, I'll provide text files tomorrow (these contain a bit more private info, so I'll need to redact a few things). Thank you! |
|
I put both logfiles in a gist here: https://gist.github.com/redclov3r/6df35e94899cd22b4f21626efa81b94e Let me know if there is something that could point me in a direction. |
|
Thanks, I'm looking through them now, will let you know what I find |
|
Looking at the traces, it appears that the connection failure happens during the start of the login sequence, which is very unusual. To investigate further, could you do a WireShark capture of both cases? That way we can see if the prelogin sequences sent to and received from the server are different between them. The other thing that could be helpful is BIDTrace, which will give more detailed logging of ODBC driver, so we may be able to narrow down where exactly the failure happens. To enable it in /etc/odbcinst.ini file in the driver section add the following: Size is in bytes, the actual files that will be created will be called file1.txt, file2.txt etc. But in this case there shouldn't be more then one |
|
Good news for once... By capturing the connection sequence with WireShark and comparing the captures, I finally found the one minor - but obviously significant - difference between the two! Both captures showed TCP packets for a pre-login request, after which the PHP version just stopped and the sqlcmd kept on with doing SSL handshake, login, etc. I then exported both captures to textfiles to compare them line by line with The php-mssql connection had While my main issue seems to be resolved there are a few questions left:
In any case: Thank you very much for your effort on resolving this. Much appreciated! |
|
Great! In retrospect it makes sense, since data warehouse doesn't support MARS and it's on by default in PHP driver. But the lack of a clear error makes it difficult to figure out. I will be looking at the docs to add this for sure, as this is a very unintuitive issue otherwise. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PHP version: 8.3.8
PHP SQLSRV or PDO_SQLSRV version 5.12.0
Microsoft ODBC Driver version 18.3.3.1-1
Client operating system Fedora Linux
Problem description
I am trying to connect to an SQL-Endpoint of a DataWarehouse / -Lakehouse which is running inside of Microsoft Fabric. The connection works as expected when using DBeaver (which uses JDBC internally) and also with
sqlcmd.$ sqlcmd -S [warehouse-id].datawarehouse.fabric.microsoft.com -U '[my-username]' -GWhen I try to establish the same connection with
sqlsrv_connectin PHP, I get the following behavior:This fails almost instantly and without any hint of the possible error. I enabled logging for SQLSRV and all I get is
sqlsrv_connect: enteringand immediately after that thevar_dump($conn)returning false.By now, I've found out that as soon as I add an instancename, like:
the command will try to connect for ~15 seconds and then fail with one of these two errors:
TCP Provider: Error code 0x2AF9MAX_PROVS: Error Locating Server/Instance Specified [xFFFFFFFF]Since I don't know the instance name (if there is one) this doesn't really help me that much.
Expected behavior and actual behavior
I expect the
sqlsrv_connectcommand to at least try to connect to the given server URL, even when there is no instance specified. Furthermore I would expect some kind of error message detailing why the function returnedfalse.The text was updated successfully, but these errors were encountered: