[MSSQL+Linux+PHP] MSSQL vanaf CentOS met PHP = segfault

[.Johnny]

We proberen hier met een aantal teams die uit verschillende achtergronden komen, samen te werken (microsoft en linux based). Het microsoft team heeft een windows server met MSSQL. Zelf werk ik vanuit het linux team op een CentOS 5.5 server (met een hele zwik tools die nu even niet ter zake doet).

Voor de interactie willen we de MSSQL omgeving queryen vanuit de CentOS box. Ik heb ongeveer deze tutorial gevolgd en kan met tsql de MSSQL omgeving queryen:
http://www.petri.co.il/ho...erver-to-a-sql-server.htm

dat gaat allemaal goed.

Het liefst willen we vanuit de CentOS box PHP gebruiken om data te injecteren in de MSSQL database, te queryen en vervolgens resultaten mee terug te nemen.

Ik heb zowel odbc als PDO gebruikt, daarbij beginnen de vreemde dingen.
Bij ODBC merk ik dat ik segmentation faults krijg als ik bijvoorbeeld een groot text veld meeneem in een query, ook al staat er niet echt veel informatie in.
Met PDO heb ik bij het toevoegen van sommige velden soms ook een Segmentation fault, als ik SELECT * doe krijg ik bij de tabel waar ik mee test zelfs geen enkel resultaat, ook geen foutmelding, maar als ik een paar kolommen aangeef in de SELECT werkt het weer wel etc.

Zijn er mensen die ervaring hebben met een dergelijke setup, die dit probleem bekend voorkomt? Misschien wat hints in welke richting ik het zou moeten zoeken?

[ipsec]

Welke PHP versie gebruik je precies? En met welke options heb je PHP gecompiled? Dit kan je eventueel via een phpinfo(); bestandje wel even uitlezen. Welke MSSQL versie staat er op de MSSQL machine?
Heb je op de MSSQL machine TCP/IP aan staan? (SQL Server Configuration Manager -> Network Configuration -> Protocol)

Er zijn nogal wat bugs bekend betreffende jou foutmelding en PHP/MSSQL. Dus misschien dat je ons alsnog van wat meer informatie kunt voorzien :-)

[ Voor 21% gewijzigd door ipsec op 03-09-2013 16:29 ]

[kwaakvaak_v2]

Centos is RH compatible dus je zou in principe http://www.microsoft.com/...oad/details.aspx?id=28160 kunnen gebruiken met http://www.php.net/manual/en/ref.pdo-odbc.php ?

[.Johnny]

@SuperKevin; TCP/IP is enabled

Ik merk dat de odbc query failt op 1 specifieke rij, en daarbinnen op 1 specifiek veld. Het zijn niet vreselijk veel tekens, dat een seqfault in lijn van verwachting ligt in dit specifieke geval: 4452. Het veldtype is (nvarchar(max),null)

@kwaakvaak; ik zal daar eens naar kijken!

[RobIII]

.Johnny schreef op dinsdag 03 september 2013 @ 16:58:
@SuperKevin; TCP/IP is enabled

Ik merk dat de odbc query failt op 1 specifieke rij, en daarbinnen op 1 specifiek veld. Het zijn niet vreselijk veel tekens, dat een seqfault in lijn van verwachting ligt in dit specifieke geval: 4452. Het veldtype is (nvarchar(max),null)

@kwaakvaak; ik zal daar eens naar kijken!

nvarchar(max) is ("vroeger") een poos 4000 geweest volgens mij, en het zou me niets verbazen (los daarvan) als de implementatie bijv. 4k (4096) bytes accepteert. Ik zou eens testen op die "edge cases" dus met velden van 3999, 4000, 4001, 4095, 4096 en 4097 bytes.

edit:
varchar was iig. 8000 bytes, met een specifieke (2-byte per char) collatie bijvoorbeeld kom je dus op 4000 uit. Als de specifieke implementatie die je gebruikt daar op gebouwd is i.p.v. de recentere limieten dan kan ik me voorstellen dat dat problemen/segfaults geeft.

[ Voor 20% gewijzigd door RobIII op 03-09-2013 17:17 ]

[.Johnny]

Kudo's. Dit klinkt heel aannemelijk. Ik ga eens een test case maken in een tijdelijke tabel.

Hopelijk zit het probleem in freetds en is het op te lossen door naar de MS ODBC driver te switchen...

[_Peter2_]

Je gebruikt ook een redelijk oude versie van CentOS. (En CentOS an sich gebruikt ook weer niet bleeding edge versies van software).

Zover ik weet is voor CentOS 5 al een tijdje 5.9 uit wellicht dat de (iets) nieuwere packages ook fixes voor je probleem bevatten.

[.Johnny]

@_peter2_: de laatste versie van freetds is 0.91, die staat erop.

Ik heb even met een aantal inserts zitten spelen en het lijkt inderdaad op 4096 max bytes stuk te lopen:

PHP:

$s='';
for($a=0;$a<2049;$a++) {
    $s.='å';
}
$sql='
DECLARE @n NVARCHAR(max);
SELECT @n = \''.$s.'\';
SELECT  DATALENGTH(@n);';
$rr = odbc_exec($ms_dbconn,$sql);
if (!$rr) { die(odbc_errormsg()); }
while($r=odbc_fetch_object($rr)) {
    print_r((array)$r);
}

(
[4098] => 4098
)

PHP:

$sql='CREATE TABLE #MyNVarCharTest ( someid INT, somevar nvarchar(max));
INSERT INTO #MyNVarCharTest (someid,somevar) VALUES (1,N\''.$s.'\');
SELECT * FROM #MyNVarCharTest
';
$rr = odbc_exec($ms_dbconn,$sql);
if (!$rr) { pl(odbc_errormsg()); exit; }
while($r=odbc_fetch_object($rr)) {
    print_r((array)$r);
}

Segmentation fault


Het is dus niet perse 3999 characters: niet elke character neemt evenveel bytes in beslag, het is kennelijk adaptief.

Volgende stap: de microsoft driver aan de praat krijgen.

Ongerelateerde opmerking, maar ik merkte ook dat het niet lukt om met verschillende odbc calls naar 1 temp table te verwijzen, ik moet alles in 1 sql statement zetten als ik iets met een temp table wil doen. Is dat normaal? Met MySQL ben ik gewend dat een sessie in PHP open blijft en de temp table pas aan het einde weg is.

[.Johnny]

Met de driver van MS lijkt dit inderdaad te werken!

PHP:

$query1='CREATE TABLE #MyNVarCharTest ( someid INT, somevar NVARCHAR(max));';
$query2='INSERT INTO #MyNVarCharTest (someid,somevar) VALUES (1,N\''.$s.'\');';
$query2.='INSERT INTO #MyNVarCharTest (someid,somevar) VALUES (2,N\'ABCDEFGH\');';
$query3='SELECT * FROM #MyNVarCharTest;';
$sql=$query1.$query2.$query3;
$statement = $db->prepare($sql);
$statement->execute();
$statement->nextRowset();
$statement->nextRowset();
$result = $statement->fetchAll(PDO::FETCH_NUM);
print_r($result);
exit;
while($result = $statement->fetch(PDO::FETCH_ASSOC)) {
    pl(print_r($result,true));
}

Er blijven nog steeds de nodige rariteiten;

• PHP:
  

  $sql='CREATE TABLE #MyNVarCharTest ( someid INT, somevar nvarchar(max));';
  $rr = odbc_exec($ms_dbconn,$sql);

  
  is direct een segmentation fault.
• odbc_fetch_object op de tabel waarop ik oorspronkelijk teste werkt ook niet: PHP Warning: odbc_fetch_object(): SQL error: [Microsoft][SQL Server Native Client 11.0]Invalid Descriptor Index, SQL state S1002 in SQLGetData in [file]
  het lijkt erop dat de standaard odbc implementatie van PHP niet overweg kan met deze ODBC driver.
• Met PDO is dat probleem er niet, maar als ik zelf een temp table aanmaak met nvarchar(max) is dat veld in een select altijd leeg; als ik bv nvachar(4000) doe werkt dat wel goed. Vreemd genoeg mag ik niet meer dan 4000 kiezen, anders krijg ik weer een andere foutmelding. Kies ik boven de 8000, dan krijg ik als foutmelding:
  
  code:
  

  SQLSTATE[42000]: Syntax error or access violation: 131 [Microsoft][SQL Server Native Client 11.0][SQL Server]The size (9000) given to the column 'somevar' exceeds the maximum allowed for any data type (8000)

  
  Maar kies ik tussen 4000 en 8000, dan krijg ik een andere foutmelding:
  
  code:
  

  SQLSTATE[42000]: Syntax error or access violation: 2717 [Microsoft][SQL Server Native Client 11.0][SQL Server]The size (5000) given to the parameter 'somevar' exceeds the maximum allowed (4000)

  
  Kies ik 4000, dan gaat het goed, ook al wordt er meer data in gestopt.
• PDO: Als ik een nvarchar(max) veld selecteer, zoals ik vermeld in de OP, werkt het nu wel goed.

Er zijn dus duidelijk de nodige bugs, hoe je het ook wendt of keert. Kennelijk is het een erg ongebruikelijke setup, want er zijn ook maar weinig topics over te vinden.

[ Voor 18% gewijzigd door .Johnny op 04-09-2013 13:12 ]

[_Peter2_]

.Johnny schreef op woensdag 04 september 2013 @ 10:30:
Het is dus niet perse 3999 characters: niet elke character neemt evenveel bytes in beslag, het is kennelijk adaptief.

Wellicht gerelateerd aan UTF-8. (Daarin nemen sommige characters immers 2 of meer bytes in beslag)