Testing if a bug comes from PDO_4D

[Alexandre Morgaut]

All of these tests will make you win (and us) lot of time ;-)


A good test is to first try your SQL request from 4D itself


First on the 4D holding the targeted database

Example:

Begin SQL

SELECT foo FROM bar INTO :$baz

End SQL

ALERT("baz: " + String($baz))

You will then detect if the request is supported by the 4D SQL engine



Then from a remote 4D, using "SQL Login" before "Begin SQL"

SQL Login($4D_ODBC_DSN; $login; $password)

You will detect then if the problems comes from authentication or from
the communication protocol


If it worked from both of these methods, and doesn't from PDO_4D, then
the problem comes from either the PHP code or the PDO_4D driver.

Please then, don't forget to use try/catch and test the result of the
PDO error messages
- connection level: http://www.php.net/manual/en/pdo.errorinfo.php
- statement level: http://www.php.net/manual/en/pdostatement.errorinfo.php

[Alexandre Morgaut]

Well I just forgot... some problems can also come from the PDO
extension itself

In this case, as PDO became part of the core PHP package, the bug
would have to be posted on the PHP Bug base


Check before if it hasn't already be posted, and add your comments to
help the resolution

http://bugs.php.net/search.php?cmd=display&search_for=pdo&x=2&y=4

[Alexandre Morgaut]

An important enhancement to this process

> Then from a remote 4D, using "SQL Login" before "Begin SQL"
>
> SQL Login($4D_ODBC_DSN; $login; $password)
>
> You will detect then if the problems comes from authentication or from
> the communication protocol

Via ODBC, there can subtle differences in the behaviors due to the
ODBC layer

It is then better to connect to the remote 4D Base SQL Server using
either the 'IP:...' or the '4D:...' syntax.

ex:

SQL LOGIN("IP:192.168.45.34";"John";"azerty")

http://doc.4d.com/4D-Language-Reference-12.1/SQL/SQL-LOGIN.301-479334.en.html