Felsök Microsoft-drivrutinerna för PHP för SQL Server

Ladda ned PHP-drivrutin

Diagnostisera och lösa vanliga problem när du använder Microsoft Drivers för PHP för SQL Server för att ansluta till SQL Server, Azure SQL Database, Azure SQL Managed Instance och SQL Database i Microsoft Fabric.

För allmänna mönster för hantering av fel och varningar, se Hantering av fel och varningar. För diagnostik på förarsidan, se Loggning av aktivitet.

Installationsproblem

Förlängning som inte laddas

Symtom:

  • phpinfo() Listar inte en sqlsrv eller sektion pdo_sqlsrv .
  • PDOException: could not find driver när man konstruerar en PDO med sqlsrv: DSN.
  • Fatal error: Uncaught Error: Call to undefined function sqlsrv_connect().

Möjliga orsaker och lösningar:

  • Tillägg inte aktiverat i php.ini. Kontrollera att både och extension=sqlsrvextension=pdo_sqlsrv är okommenterade att det inte är kommenterat. På Windows, använd hela filnamnet (extension=php_sqlsrv_84_ts_x64.dll). För detaljer, se Laddar drivrutinerna.
  • Fel trådsäkerhetskonstruktion. Drivrutinsbinären måste matcha din PHP-builds trådsäkerhet (ts för trådsäker, nts för icke-trådsäker). Kör php -i | grep "Thread Safety" för att kontrollera. Ladda ner den matchande binären från nedladdningssidan.
  • Microsoft ODBC-drivrutin saknas. PHP-drivrutinerna omsluter Microsoft ODBC-drivrutinen för SQL Server. På Linux och macOS, installera msodbcsql18 (eller msodbcsql17) med din pakethanterare innan du laddar tilläggen. På Windows, installera ODBC-drivrutinen från nedladdningssidan.

Verifiera en lyckad installation:

php -m | grep -i sqlsrv

Du bör se både och pdo_sqlsrvsqlsrv i utgången.

PECL-installationen misslyckas på Linux eller macOS

Symtom:

error: ‘SQL_HANDLE_DBC’ undeclared (first use in this function)
fatal error: 'sql.h' file not found

Lösningen

Installera ODBC-utvecklingsheaders innan du kör:pecl install

  • Ubuntu och Debian: sudo apt-get install unixodbc-dev
  • Red Hat, Fedora och CentOS:sudo dnf install unixODBC-devel
  • Alpin:apk add unixodbc-dev
  • macOS:brew install unixodbc

Försök sedan igen:

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv

Om pecl det fortfarande misslyckas efter att headers installerats kan byggverktygskedjan vara ofullständig. Installera phpize, re2c, och en C++-kompilator (build-essential på Debian och Ubuntu, gcc-c++ make på Red Hat och Fedora, build-base på Alpine).

För hela installationsvägen, se installationsguide för Linux och macOS.

Flera PHP-versioner installerade

Symtom:

phpinfo() din webbserver visar en PHP-version, men php -v på kommandoraden visas en annan, och drivrutinen visas laddad i bara en av dem.

Lösningen

Varje PHP-version har sin egen php.ini katalog ext . Hitta rätt konfigurationsfil i php --ini miljön som saknar drivrutinen, och lägg till raderna extension= där. Starta om webbservern (Apache, Nginx + PHP-FPM eller IIS) efter varje php.ini ändring.

Anslutningsproblem

Kan inte ansluta till servern

Symtom:

SQLSTATE[08001]: [Microsoft][ODBC Driver 18 for SQL Server]TCP Provider: A connection attempt failed
SQLSTATE[HYT00]: [Microsoft][ODBC Driver 18 for SQL Server]Login timeout expired

Möjliga orsaker och lösningar:

  • Servern är inte nåbar. Kontrollera att servernamnet och porten är korrekta. Från PHP-värden, testa rå TCP-anslutning.

    # Linux and macOS
    nc -vz <server>.database.windows.net 1433
    
    # Windows PowerShell
    Test-NetConnection -ComputerName <server>.database.windows.net -Port 1433
    
  • Brandvägg blockerar utgående 1433. Företagsbrandväggar och moln-NSG:er blockerar ofta utgående port 1433. Lägg till ett undantag, eller tillåt Azure SQL Database IP-intervall för din region.

  • Azure SQL server firewall. Lägg till din klients publika IP i servernivåns brandväggsregler i Azure-portalen.

  • Namngiven instans. För en namngiven instans, kontrollera att SQL Server Browser-tjänsten körs på servern och att UDP 1434 är öppen. Eller koppla upp via port istället för efter instansnamn.

Inloggningen misslyckades

Symtom:

SQLSTATE[28000]: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user '<user_id>'.

Möjliga orsaker och lösningar:

  • SQL-autentiseringsläge inaktiverat. Lokala SQL Server-instanser använder som standard endast Windows-autentisering. Aktivera mixed mode-autentisering i SQL Server Management Studio under Server properties>Security och starta sedan om SQL Server-tjänsten.
  • Azure SQL credentials format. Azure SQL kräver det fullt kvalificerade användarnamnet (user@servername) när man ansluter från verktyg som inte automatiskt lägger till det.
  • Användaren är inte mappad till databasen. Verifiera att inloggningen har en användarmappning i måldatabasen och att användaren har de nödvändiga behörigheterna.
  • Föredrar Microsoft Entra ID. För Azure SQL, Azure SQL Managed Instance och SQL-databas i Fabric, använd Microsoft Entra-autentisering (Authentication=ActiveDirectoryMsi, Authentication=ActiveDirectoryServicePrincipal, eller en åtkomsttoken) istället för SQL-inloggningar. Se Ansluta med Microsoft Entra-autentisering.

Ogiltigt värde angivet för attributet 'Authentication i reťazec pripojenia

Symtom:

SQLSTATE[08001]: [Microsoft][ODBC Driver 17 for SQL Server]Invalid value specified for connection string attribute 'Authentication'

Orsak:

ODBC-drivrutinen rapporterar felet, men det verkliga problemet är vilken drivrutin PDO_SQLSRV bunden till. Om DSN inte innehåller ett Driver= nyckelord och värden har både ODBC 17 och ODBC 18 installerat, kan PDO_SQLSRV binda till den äldre versionen. Äldre ODBC 17.x-versioner känner inte till nyare Authentication värden som ActiveDirectoryServicePrincipal eller ActiveDirectoryDefault, och kräver till och med ActiveDirectoryMsi ODBC 17.3.1.1 eller en senare version.

Lösningen

Fäst drivrutinen i DSN:n:

<?php
$dsn = "sqlsrv:Driver={ODBC Driver 18 for SQL Server};Server=$server;Database=$db;" .
       "Encrypt=true;Authentication=ActiveDirectoryMsi";
$conn = new PDO($dsn, null, null, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);

Den parenteserade formen ({ODBC Driver 18 for SQL Server}) undviker mellandragen i förarnamnet. Felmeddelandet i sig namnger alltid drivrutinen som rapporterade det, så prefixet [Microsoft][ODBC Driver 17 for SQL Server] i felet är det snabbaste sättet att bekräfta fel drivrutinsgräns.

Ogiltigt nyckelord 'UID' specificerades i DSN-strängen

Symtom:

SQLSTATE[IMSSP]: An invalid keyword 'UID' was specified in the DSN string.

Orsak:

PDO_SQLSRV upprätthåller en tillåtningslista med DSN-nyckelord och accepterar UID inte eller PWD finns i DSN. PDO reserverar argumenten för den andra och tredje konstruktören för dessa, och PDO_SQLSRV översätter dem internt till ODBC UID/PWD .

Lösningen

Flytta användarnamnet (och lösenordet, för SQL-autentisering) till PDO-konstruktorn:

<?php
// SQL authentication.
$dsn = "sqlsrv:Driver={ODBC Driver 18 for SQL Server};Server=$server;Database=$db;Encrypt=true";
$conn = new PDO($dsn, $user, $password);

// User-assigned managed identity. Pass the identity's client ID as $username.
$dsn = "sqlsrv:Driver={ODBC Driver 18 for SQL Server};Server=$server;Database=$db;" .
       "Encrypt=true;Authentication=ActiveDirectoryMsi";
$conn = new PDO($dsn, $clientId, null);

SQLSRV-procedurdrivrutinen, däremot, accepterar UID och PWD i anslutningsoptionsarrayen skickas till sqlsrv_connect().

PDO_SQLSRV ignorerar tyst AccessToken i optionsmatrisen

Symptom:

Du har en Microsoft Entra access-token (till exempel från az account get-access-token --resource https://database.windows.net/, , eller ClientSecretCredential), och du skickar den till PDO_SQLSRV som ['AccessToken' => $token] i det fjärde konstruktörargumentetManagedIdentityCredential. Anslutningsförsöket misslyckas med ett förvirrande fel, som Windows logins are not supported in this version of SQL Server eller Login failed for user '', som om inga inloggningsuppgifter angavs.

Orsak:

PDO:s fjärde konstruktörargument är reserverat för drivrutinsspecifika attributkonstanter (heltalsnycklar såsom PDO::ATTR_ERRMODE). PDO släpper tyst strängnyckelposter som AccessToken, så PDO_SQLSRV ser aldrig tokenen. Anslutningen återgår sedan till Windows Integrerad autentisering, som servern avvisar.

Lösningen

Gå in AccessToken i DSN-strängen. Reservera optionsarrayen för PDO::ATTR_* konstanter.

<?php
$server = '<server>.database.windows.net';
$token  = getenv('SQL_ACCESS_TOKEN');   // raw JWT, no "Bearer " prefix

$dsn = "sqlsrv:Server=$server;Database=<database>;Encrypt=true;AccessToken=$token";
$conn = new PDO($dsn, null, null, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

För ytterligare exempel på Microsoft Entra autentisering, inklusive DSN-formuläret för PDO_SQLSRV, se Connect using Microsoft Entra authentication.

För SQLSRV-procedural AccessToken hör den till connection-info-arrayen som skickas till sqlsrv_connect(), vilket faktiskt omsluter rå JWT till SQL_COPT_SS_ACCESS_TOKEN för dig:

<?php
$server = '<server>.database.windows.net';
$token  = getenv('SQL_ACCESS_TOKEN');   // raw JWT, no "Bearer " prefix

$connectionInfo = [
    'Database'               => '<database>',
    'AccessToken'            => $token,
    'Encrypt'                => true,
    'TrustServerCertificate' => false,
    'Driver'                 => '{ODBC Driver 18 for SQL Server}',
];

$conn = sqlsrv_connect($server, $connectionInfo);
if ($conn === false) {
    print_r(sqlsrv_errors());
    exit(1);
}

TLS-certifikatfel

Symtom:

SQLSTATE[08001]: SSL Provider: The certificate chain was issued by an authority that is not trusted
SQLSTATE[08001]: SSL Provider: The target principal name is incorrect

Lösningar:

Föredra ett betrodd certifikat. Använd TrustServerCertificate=true endast för lokal utveckling mot en server som du kontrollerar.

För utveckling mot ett självsignerat certifikat:

<?php
$server   = 'localhost';
$database = '<database>';
$user     = '<user_id>';
$password = '<password>';

$dsn = "sqlsrv:Server=$server;Database=$database;Encrypt=true;TrustServerCertificate=true";
$conn = new PDO($dsn, $user, $password, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

Caution

TrustServerCertificate=true Inaktiverar validering av servercertifikat. Ta aldrig med den miljön in i produktion, iscensättning eller delade miljöer.

För ett produktionsvärdnamn som inte matchar certifikatets gemensamma namn (till exempel när man ansluter via en lyssnare), ange det faktiska certifikatämnet:

<?php
$dsn = "sqlsrv:Server=<listener>;Database=<database>;Encrypt=true;HostNameInCertificate=*.database.windows.net;Authentication=ActiveDirectoryMsi";
$conn = new PDO($dsn, null, null, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

Tidsgräns för anslutning

Symtom:

SQLSTATE[HYT00]: Login timeout expired

Möjliga orsaker och lösningar:

  • LoginTimeout Inte inställd eller för låg för kall failover. Ställ in en explicit LoginTimeout (i sekunder) i DSN när du ansluter till Azure SQL. Failover-grupp-failovers och kallstartsdatabaser kan ta längre tid än en kort klienttidsavbrott tillåter. Se anslutningsalternativ för referensen till alternativ.
  • Ledig återanslutningsbudget förkortad. Om du sätter ConnectRetryCount och ConnectRetryInterval, se till att LoginTimeout >= ConnectRetryCount * ConnectRetryInterval. Annars avslutar inloggningstiden återanslutningsloopen tidigt. Se Vilolägesanslutningsresiliens.
<?php
$dsn = "sqlsrv:Driver={ODBC Driver 18 for SQL Server};Server=<server>.database.windows.net;Database=<database>;" .
       "Encrypt=true;LoginTimeout=90;ConnectRetryCount=5;ConnectRetryInterval=15;" .
       "Authentication=ActiveDirectoryMsi";
$conn = new PDO($dsn, null, null, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

Problem med förfrågningsexekvering

Tysta fel med PDO

Symptom:

A PDO::exec() eller PDOStatement::execute() anrop återvänder false men kastar inget undantag.

Lösningen

Med PHP 8.0 och senare versioner är PDO::ERRMODE_EXCEPTIONstandardfelet i PDO. Om ett anrop återvänder false utan att kasta har applikationen ändrat läget till PDO::ERRMODE_SILENT eller PDO::ERRMODE_WARNING. Sätt tillbaka den till undantagsläge så att misslyckanden ger undantag:

<?php
$conn = new PDO($dsn, $user, $password, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

Om du inte kan ändra läget globalt, kontrollera $conn->errorInfo() (eller $stmt->errorInfo()) efter varje samtal. Matrisen innehåller [SQLSTATE, driver code, driver message].

Ogiltigt objektnamn

Symtom:

SQLSTATE[42S02]: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Invalid object name 'Products'.

Möjliga orsaker och lösningar:

  • Fel databaskontext. Verifiera med en snabb fråga:

    <?php
    $stmt = $conn->query("SELECT DB_NAME()");
    echo $stmt->fetchColumn();
    
  • Saknad schema-kvalificerare. Använd fullt kvalificerade namn för att undvika att behöva använda uppringarens standardschema:

    SELECT * FROM dbo.Products;
    
  • Skiftlägeskänslighet. Databaser skapade med en kasuskänslig sortering behandlar products och Products som olika objekt. Matcha det exakta fallet i tabelldefinitionen.

Fel antal parametrar

Symtom:

SQLSTATE[HY093]: Invalid parameter number
SQLSTATE[07002]: COUNT field incorrect or syntax error

Lösningen

För PDO_SQLSRV måste antalet ? platshållare matcha antalet värden du skickar till execute(), och varje ? binder en enda skalär (inte en array). För namngivna parametrar måste varje :name i SQL visas i matrisen och vice versa.

<?php
$stmt = $conn->prepare(
    "SELECT * FROM dbo.Products WHERE CategoryID = ? AND ListPrice > ?"
);
$stmt->execute([1, 50.0]);
foreach ($stmt as $row) {
    // ...
}

För SQLSRV, skicka parameterarrayen till sqlsrv_query() eller sqlsrv_prepare():

<?php
$stmt = sqlsrv_query(
    $conn,
    "SELECT * FROM dbo.Products WHERE CategoryID = ? AND ListPrice > ?",
    [1, 50.0]
);
if ($stmt === false) {
    die(print_r(sqlsrv_errors(), true));
}

För en bredare introduktion till parameterbindning, se Utför parameteriserade frågor.

PDO-emulerad förbereder maskfel

Symtom:

Ett uttalande körs framgångsrikt på en anslutning men kastar ett syntaxfel på en annan anslutning som använder samma frågetext.

Orsak:

PDO_SQLSRV stöder både emulerade och inbyggda förberedda satser. Emulerade förbereder (PDO::ATTR_EMULATE_PREPARES = true) interpolerar parametrar på klientsidan. Native förbereder (false) skickar frågan och parametrarna separat till servern. Beteendet skiljer sig åt för TOP (?)tabellvärda parametrar och vissa gränsfall i typ-koercion.

Lösningen

Föredrar inhemska förberedelser i produktion. Ställ PDO::ATTR_EMULATE_PREPARES => false in vid anslutningstid så att beteendet är konsekvent över miljöer:

<?php
$conn = new PDO($dsn, null, null, [
    PDO::ATTR_ERRMODE          => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
]);

För detaljer om när varje läge ska användas, se PDO::p repare.

Datatypproblem

Unicode-tecken visas som ? eller förvrängda

Symtom:

Rader som PHP skriver innehåller frågetecken eller ersättningstecken istället för de ursprungliga icke-ASCII-tecknen. Läsningarna svarar på osammanhängande text.

Möjliga orsaker och lösningar:

  • Kolumntypen är VARCHAR, inte NVARCHAR. varchar-kolumner använder en kodsida, inte Unicode. Använd nvarchar för internationaliserad text.

  • Saknar UTF-8-kodningstips på PDO_SQLSRV. När din SQL Server-kolumn är nvarchar och din PHP-data är UTF-8, be drivrutinen konvertera mellan UTF-8 (klient) och UTF-16 (server):

    <?php
    $conn = new PDO(
        "sqlsrv:Server=<server>;Database=<database>;Encrypt=true",
        $user,
        $password,
        [
            PDO::ATTR_ERRMODE                    => PDO::ERRMODE_EXCEPTION,
            PDO::SQLSRV_ATTR_ENCODING            => PDO::SQLSRV_ENCODING_UTF8,
        ]
    );
    
  • SQLSRV-drivrutin: begär explicit UTF-8. SQLSRV_ENC_CHAR är standardkodsidan för 8-bitars systemet, inte UTF-8. För UTF-8 med SQLSRV, sätt "CharacterSet" => "UTF-8" på anslutningen och skicka literalen 'UTF-8' till SQLSRV_PHPTYPE_STRING vid hämta eller binda. Se Skicka och hämta UTF-8-data.

Fel vid konvertering av datum och tid

Symtom:

SQLSTATE[22007]: Invalid character value for cast specification

Lösningen

På PDO_SQLSRV, bind inte ett rått DateTime föremål. PDO stringifierar bundna värden innan bindning, och PHP DateTime har ingen __toString() metod, så execute([new DateTime(...)]) höjer Object of class DateTime could not be converted to string. Formatera värdet först, eller skicka en ISO 8601-sträng (YYYY-MM-DD HH:MM:SS[.fff]), inte en lokalformaterad sträng.

<?php
$stmt = $conn->prepare("INSERT INTO dbo.Events (EventDate) VALUES (?)");
$stmt->execute([(new DateTime("2026-03-15 10:00:00"))->format("Y-m-d H:i:s.u")]);

För att hämta datetime-kolumner som DateTime objekt istället för strängar på PDO_SQLSRV, sätt attributet statement:

<?php
$stmt = $conn->prepare("SELECT EventDate FROM dbo.Events");
$stmt->setAttribute(PDO::SQLSRV_ATTR_FETCHES_DATETIME_TYPE, true);
$stmt->execute();

För detaljer, se Hämta datumtidsobjekt (PDO_SQLSRV).

Decimalformateringsproblem

Symtom:

Värden mellan -1 och 1 saknar en inledande nolla, eller så visar värdena på pengar och småpengar ett oväntat antal decimaler.

Lösningen

PDO_SQLSRV hämtar alltid decimala och numeriska värden som strängar med exakt precision och skala. Sätt PDO::SQLSRV_ATTR_FORMAT_DECIMALS att lägga till en ledande nolla till värden mellan -1 och 1:

<?php
$conn->setAttribute(PDO::SQLSRV_ATTR_FORMAT_DECIMALS, true);

PDO::SQLSRV_ATTR_DECIMAL_PLACES gäller endast pengar och småpenningvärden . Den sätter deras visade skala från 0 till 4 och kan avrunda det visade värdet. Det påverkar inte decimala eller numeriska värden.

För detaljer, se Formatera decimaltal och pengar (PDO_SQLSRV) eller Formatera decimaler och pengar (SQLSRV).

Transaktionsproblem

Dataförändringar kvarstår inte

Symtom:

Raderna du infogar eller uppdaterar i PHP visas inte när du frågar från en annan session.

Orsak:

PDO::beginTransaction() öppnar en explicit transaktion som kräver en explicit commit(). Om PHP-skriptet avslutas utan att anropa commit(), rullar PDO tillbaka transaktionen under anslutningsrensningen.

Lösningen

Para alltid beginTransaction() ihop med commit(), och använd try/catch för att rulla tillbaka vid fel:

<?php
try {
    $conn->beginTransaction();
    $conn->exec("INSERT INTO dbo.Orders (CustomerID, Total) VALUES (1, 100)");
    $conn->exec("UPDATE dbo.Inventory SET Stock = Stock - 1 WHERE ProductID = 5");
    $conn->commit();
} catch (PDOException $e) {
    $conn->rollBack();
    throw $e;
}

För SQLSRV, använd sqlsrv_begin_transaction, sqlsrv_commit, och sqlsrv_rollback.

Dödlägesfel

Symtom:

SQLSTATE[40001]: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Transaction (Process ID 62) was deadlocked

Lösningen

Hantera tillfälliga deadlock-fel med retry-logik. Wrappa hela transaktionen (inte bara det felande satsen) så att tidigare satser spelas upp på den nya transaktionen. För ett produktionsorienterat återförsöksmönster, se exemplet på PHP-drivrutinens landningssida.

Återkommande dödlägen indikerar ett designproblem. Fånga deadlock-grafen och analysera vilka satser och låstyper som är inblandade. Vanliga lösningar inkluderar omordningsoperationer så att konkurrerande transaktioner får lås i samma sekvens, minska transaktionsomfattningen och lägga till index för att förkorta låsets varaktighet. För en fullständig genomgång, se Deadlocks-guiden.

Problem med anslutningsresiliens

Återanslutning sker inte

Symtom:

En inaktiv anslutning förblir bruten efter en Azure SQL Database-failover, även om du sätter ConnectRetryCount och ConnectRetryInterval.

Möjliga orsaker och lösningar:

  • Aktiv servermarkör. Vilolägesresiliens för anslutningar återkopplar bara lediga anslutningar. En öppen markör på serversidan eller en väntande transaktion håller anslutningen aktiv. Frigör server-side-markörer genom att använda sqlsrv_free_stmt() or $stmt = null; (PDO) före failover-fönstret, eller byt till en buffrad kursör på klientsidan. Se Vilolägesanslutningsresiliens.
  • Tillstånd för icke återställbar session. Vissa sessionstillstånd kan inte återställas, inklusive temporära tabeller, globala och lokala markörer, transaktionskontext, applikationslås, EXECUTE AS/REVERTOLE-automationshandtag, förberedda XML-handtag och spårflaggor. Något av dessa sessionstillstånd förhindrar automatisk återanslutning.
  • LoginTimeout för liten. Om ConnectRetryCount * ConnectRetryInterval > LoginTimeout, slutar drivrutinen försöka igen när LoginTimeout nås nås. Höj LoginTimeout för att täcka hela återupptagningsbudgeten.

Prestandaproblem

För diagnos och åtgärd av långsamma frågor, kallstarter, stora resultatuppsättningar och bulkinsättningar, se Performance tuning.

Aktivera drivrutinsdiagnostik

När applikationsnivåanrop error_log() inte ger tillräckligt med information, slå på loggning på förarsidan. Den rapporterar varje ODBC-samtal som föraren gör.

PDO_SQLSRV

Sätt pdo_sqlsrv.log_severity in php.ini och starta om webbservern. Denna inställning är endast läsbar vid initialisering:

[pdo_sqlsrv]
pdo_sqlsrv.log_severity = 1

Värden är 0 (av, standard), -1 (fel, varningar och meddelanden), 1 (fel), 2 (varningar) och 4 (meddelanden).

SQLSRV

Aktivera loggning vid körning med sqlsrv_configure():

<?php
sqlsrv_configure("LogSubsystems", SQLSRV_LOG_SYSTEM_CONN | SQLSRV_LOG_SYSTEM_STMT);
sqlsrv_configure("LogSeverity", SQLSRV_LOG_SEVERITY_ERROR | SQLSRV_LOG_SEVERITY_WARNING);

Loggposter går till filen konfigurerad av error_log i php.ini. För hela listan över delsystem och allvarlighetsgrader, se Loggningsaktivitet.

Container- och CI-problem

Saknade systembibliotek på Linux

Symtom:

error while loading shared libraries: libodbc.so.2: cannot open shared object file
error while loading shared libraries: libssl.so.1.1: cannot open shared object file

Lösningen

Installera runtime-beroendena innan du installerar PHP-drivrutinen:

Distribution Installationskommando
Ubuntu och Debian sudo apt-get install unixodbc libgssapi-krb5-2
Red Hat och Fedora sudo dnf install unixODBC krb5-libs
Alpine apk add unixodbc gcompat

Installera msodbcsql18 sedan från Microsoft paketförråd. För distributionsspecifika paketarkiv och versioner, se ODBC:s drivrutinsinstallationsguide.

Docker-bildbyggen lyckas men anslutningarna misslyckas vid körning

Symtom:

Avbilden byggs och PHP startar, men PDO::__construct() ger ett ODBC-drivrutinsfelmeddelande.

Lösningen

Verifiera att ODBC-drivrutinen är installerad i runtime-avbilden, inte bara i byggsteget. Installera msodbcsql18 och unixodbc-dev i samma fas som skickas till produktion. I en flerstegsbyggnation, installera dem i slutsteget. En enstegsinstallation baserad på Debian ser ut så här:

# Pin to a specific PHP minor version in production, for example php:8.4.11-cli.
FROM php:8.4-cli
RUN apt-get update && apt-get install -y --no-install-recommends \
        curl gnupg2 apt-transport-https ca-certificates \
    && curl -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > /usr/share/keyrings/microsoft.gpg \
    && echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/debian/12/prod bookworm main" > /etc/apt/sources.list.d/mssql-release.list \
    && apt-get update \
    && ACCEPT_EULA=Y apt-get install -y --no-install-recommends msodbcsql18 unixodbc-dev \
    # $PHPIZE_DEPS ships in the official php image and includes gcc, make, autoconf, and re2c.
    && apt-get install -y --no-install-recommends $PHPIZE_DEPS \
    && pecl install sqlsrv pdo_sqlsrv \
    && docker-php-ext-enable sqlsrv pdo_sqlsrv \
    && apt-get purge -y --auto-remove $PHPIZE_DEPS \
    && rm -rf /var/lib/apt/lists/*