ADODB AutoExecute() problem with mssqlnative driver about msphpsql

[v-mabarw]

On 2011-12-28 03:04:57 UTC, dolphy17 commented:

Hi dev,

Is there any update available on this issue?
It's quite a breaking one and should be prioritised I think.

Thanks,
Dolphy

[v-mabarw]

On 2011-12-28 03:26:53 UTC, dolphy17 commented:

Situation is a bit better in ADOdb 5.14, but FetchField() still not populates type field in the return object correctly. Quick fix should be something like: (in FetchField() at adodb-mssqlnative.inc.php:705)

...
} else {
$f = new ADOFetchObj();
$f->name = $arrKeys[$this->fieldOffset];
$f->type = gettype($this->fields[$f->name]);
if($fieldOffset == -1) $this->fieldOffset++;
}
...

[v-mabarw]

On 2011-12-28 03:37:02 UTC, deoid commented:

Hi.

I don't think theres a fix for this, it happens using ADODB class, so the problem is in this class. The driver itself works fine.

Recently i tried the new versions of this driver (2.0 and 3.0), with ADODB 5.14 and the problem still exists, so i'm still using my modified adodb-mssqlnative.inc.php file, available here as attachment.

It's being used in many professional projects and so far theres no problem with it.

[v-mabarw]

On 2011-12-28 04:03:05 UTC, dolphy17 commented:

Thanks deoid.
Your driver works fine to me.

[v-mabarw]

On 2011-12-31 04:49:04 UTC, jguerin commented:

Hi Dolphy,

In order for us to be able to reproduce this problem, we would require the functions which are being called on the driver itself (sqlsrv_), the expected result, and the result you are receiving.

Would you be able to provide and example of this behavior so that we can investigate this?

Thanks,

Jonathan

[v-mabarw]

On 2011-12-31 05:14:26 UTC, dolphy17 commented:

Why did you close the issue?
This is not a bug in the application, this is a blocking issue in the framework's driver.

Basically, nobody can use the AutoExecute() functionality with this driver currenty.

Usage example:
...
$row['user_email'] = $this->email;
$row['user_testemail'] = $this->testemail;
$row['user_default_subject'] = $this->default_subject;
$this->db->AutoExecute($table, $row, 'UPDATE', "user_id=".$this->id);

Crashes and throws exception.

[v-mabarw]

On 2011-12-31 05:47:25 UTC, jguerin commented:

Hi Dolphy,

If this is an issue with AODB, you will have to file the issue with them in order to get it resolved (I don't think they check here :-)). If you believe that the issue exists in the SQLSRV driver, we would require more information.

In order for us to be able to reproduce this problem, we would require the functions which are being called on the driver itself (sqlsrv_), the expected result, and the result you are observing.

Thanks,

Jonathan

[v-mabarw]

On 2011-12-31 06:15:39 UTC, dolphy17 commented:

Apols, I got your point now. It's definitely a problem in ADOdb, not in MS' driver.

I'll file an issue there.
Thanks

[v-mabarw]

On 2011-12-31 08:23:08 UTC, deoid commented:

Actually, the sqlsrv driver might have a problem...
The ADODB driver for mssql-native has several flaws, i already posted then in their forum, but theres something about 'sqlsrv_field_metadata' that i don't understand.

The AutoExecute needs to know the field name, type and size in order to construct a query.

In mssql 'mssql_fetch_field' is used to get this data, and works just fine.
Mssql-native however uses 'sqlsrv_field_metadata' and it doesn't return the field type correctly.

Here
http://msdn.microsoft.com/en-us/library/cc296197.aspx, we can see that Type is an numeric ID, and this ID's don't match with SQLSERVER sys.types.

My workaround on ADODB driver uses an array to link this ID's with the proper sqlserver type and it works fine, but i don't think that's the best option...

And please, correct me if i'm wrong on this matter, a better solution is always welcome :-)

PS: again, sorry for my english...

[v-mabarw]

On 2012-01-13 04:28:17 UTC, jguerin commented:

Deoid,

Thanks for the feedback! The Enumeration of the types is documented here:
http://msdn.microsoft.com/en-us/library/cc296183.aspx

You are correct that they do not necessarily match the sys.types, and we have filed your suggestion for evaluation in future driver releases.

Thanks,

Jonathan