[Q] SQLMoreResults causes error in SQLFetchScroll

Hello,

I am using the method recommended to obtain a row count
from an operation.

That method relies on call SQLMoreResults


It appears, however, that that mechanism causes
an error down the stream (that I do not undersand)
in SQLFetchScroll


I have an example source file that demonstrates the problem

http://pastebin.com/m2b11b28d

It is an 'extract' of the actual ODBC calls that are going on
in from within OTL C++ library.

Essentailly non of SQL statements are working (because OTL
tries to obtain the row count and then deploys the sequence of
ODBC statements described in the example)


Wanted to ask if somebody has ran into this or if it is a bug,
how to log it (if it is allowed to be logged) and if there is a
workaround.

Thank you in advance for any help,
Vlad
--
V S P
toreason@fastmail.fm

--
http://www.fastmail.fm - A no graphics, no pop-ups email service


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

Sorry forgot to mention the actual error I am getting:

http://pastebin.com/d49e830c0

SQLSTATE = HY010
NATIVE ERROR = 0
MSG = [Microsoft][ODBC Driver Manager] Function sequence error


this is winXP 32 against postgres 8.4 latest candidate.
using pgODBC 8.03.04 ANSI










On Sun, 17 May 2009 01:58 -0400, "V S P" wrote:
> Hello,
>
> I am using the method recommended to obtain a row count
> from an operation.
>
> That method relies on call SQLMoreResults
>
>
> It appears, however, that that mechanism causes
> an error down the stream (that I do not undersand)
> in SQLFetchScroll
>
>
> I have an example source file that demonstrates the problem
>
> http://pastebin.com/m2b11b28d
>
> It is an 'extract' of the actual ODBC calls that are going on
> in from within OTL C++ library.
>
> Essentailly non of SQL statements are working (because OTL
> tries to obtain the row count and then deploys the sequence of
> ODBC statements described in the example)
>
>
> Wanted to ask if somebody has ran into this or if it is a bug,
> how to log it (if it is allowed to be logged) and if there is a
> workaround.
>
> Thank you in advance for any help,
> Vlad
> --
> V S P
> toreason@fastmail.fm
>
> --
> http://www.fastmail.fm - A no graphics, no pop-ups email service
>
>
> --
> Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-odbc
--
V S P
toreason@fastmail.fm

--
http://www.fastmail.fm - The way an email service should be


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

This is a cryptographically signed message in MIME format.

--------------ms090408030308000501010609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello Vlad,

I'm not sure that a call to SQLRowCount is allowed after a simple SELECT.
What if you change your SELECT by an UPDATE or a DELETE ?

--
Christophe Garault


--------------ms090408030308000501010609
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIKhDCC
BT4wggMmoAMCAQICAwa8eDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdS b290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENl cnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9y ZzAeFw0wOTA0
MTYxNDIyMTRaFw0xMTA0MTYxNDIyMTRaMEQxGzAZBgNVBAMTEkNocmlzdG9w aGUgR2FyYXVs
dDElMCMGCSqGSIb3DQEJARYWY2hyaXN0b3BoZUBnYXJhdWx0Lm9yZzCCASIw DQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAOOQE63QCaPqEqjKbvivYkaI3nef9dos3tZS L6t+FY30WSdF
cf75Kg66whLwqd9hAmfldMDy5rXHjAHhApmNf/x5wdObBepclGbn4Vz49AEK bSjhZCRzydjr
zLqSgCp7TjUZETGGDlBjEi5VgB823qWt6IDq+EchtQFwlwPonrmywGn+Zs8V nO+iXwre3gb+
c9T65Z6AmcZFd7n0uBLuEqsNUGk+lwcam/tZHY2qjT2C5YiGKRh8zQdq4zIH F8FdHua8meUV
dttgC3gMk8fw1mACEZ2W1m/nL2/0gjIbaSoFqrBEy8Wzvf9ehoEb1pYlqxe2 4ij7NNXYAq5E
FhJnCb8CAwEAAaOCAQIwgf8wDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0
IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3
LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgME
BgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsG AQUFBzABhhZo
dHRwOi8vb2NzcC5jYWNlcnQub3JnMCEGA1UdEQQaMBiBFmNocmlzdG9waGVA Z2FyYXVsdC5v
cmcwDQYJKoZIhvcNAQEFBQADggIBAFvf2ZPck3MxbxfY0+epdQjr6g9ggN7m rLE5dZDvm0It
oCF0jImkGTeyz54qF/v5AVjtH9/AxvPe2zQS8jeU6GuQiaBAR/lKrJvh1pXq Yt1o3xM3h1wY
FVvQzghQT03crM9fbT7YwTIwKNQ+GcS7AaQ5Yjeiw1wHrUkW+4GfZ9PZg8wM 42XWrpzTUmeC
CimMFUhi58AQlEGEgjqlUj3Gz0xX9EZU8/EqfZX6F76UX+Vz1JtZnizgiiwd SNDS0OuaVY8f
bGBOnObMtm+Q5TTKy0rZ+PDjTYrCQj+bn0K1lJ9OjPzo4KiNLyTNOx8K9gLz GKL1gsRCOwmw
6A7a6yC/UYq/bDoPxRbvGu5RrCLsrhiPOEzfnzDJSyk3QzzZw/3z6AGOgb97 hSTrJZb6HKXR
docgbxTQHHlKcCVkZ7VtdhqRqrRrre3qZYFDVEier3X1YuJin7s8t4b1PCYE NudAZmoW1e8I
3r0tO5pSPKugyCvR1ylLdXjhJ1sLzW8SO5pqC9PQRXHa3VgJQvdZuCPTOwkU nzT44RetjRAF
4n4EzYWC8tmmonUI/KonZOjWBegoeXkMWBgvnQXxI4REWFOmYZgXw+St7V61 Xtih7Anr16rn
Fk8amugdSINK+Gata5y4qOtdzZamVcyJGDsfAlU6TlN9r57I0oFyzxoqy/ze D7RmMIIFPjCC
AyagAwIBAgIDBrx4MA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNV
BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4X DTA5MDQxNjE0
MjIxNFoXDTExMDQxNjE0MjIxNFowRDEbMBkGA1UEAxMSQ2hyaXN0b3BoZSBH YXJhdWx0MSUw
IwYJKoZIhvcNAQkBFhZjaHJpc3RvcGhlQGdhcmF1bHQub3JnMIIBIjANBgkq hkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA45ATrdAJo+oSqMpu+K9iRojed5/12ize1lIvq34V jfRZJ0Vx/vkq
DrrCEvCp32ECZ+V0wPLmtceMAeECmY1//HnB05sF6lyUZufhXPj0AQptKOFk JHPJ2OvMupKA
KntONRkRMYYOUGMSLlWAHzbepa3ogOr4RyG1AXCXA+ieubLAaf5mzxWc76Jf Ct7eBv5z1Prl
noCZxkV3ufS4Eu4Sqw1QaT6XBxqb+1kdjaqNPYLliIYpGHzNB2rjMgcXwV0e 5ryZ5RV222AL
eAyTx/DWYAIRnZbWb+cvb/SCMhtpKgWqsETLxbO9/16GgRvWliWrF7biKPs0 1dgCrkQWEmcJ
vwIDAQABo4IBAjCB/zAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6 Ly93d3cuQ0Fj
ZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB gjcKAwQGCisG
AQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH MAGGFmh0dHA6
Ly9vY3NwLmNhY2VydC5vcmcwIQYDVR0RBBowGIEWY2hyaXN0b3BoZUBnYXJh dWx0Lm9yZzAN
BgkqhkiG9w0BAQUFAAOCAgEAW9/Zk9yTczFvF9jT56l1COvqD2CA3uassTl1 kO+bQi2gIXSM
iaQZN7LPnioX+/kBWO0f38DG897bNBLyN5Toa5CJoEBH+Uqsm+HWlepi3Wjf EzeHXBgVW9DO
CFBPTdysz19tPtjBMjAo1D4ZxLsBpDliN6LDXAetSRb7gZ9n09mDzAzjZdau nNNSZ4IKKYwV
SGLnwBCUQYSCOqVSPcbPTFf0RlTz8Sp9lfoXvpRf5XPUm1meLOCKLB1I0NLQ 65pVjx9sYE6c
5sy2b5DlNMrLStn48ONNisJCP5ufQrWUn06M/OjgqI0vJM07Hwr2AvMYovWC xEI7CbDoDtrr
IL9Rir9sOg/FFu8a7lGsIuyuGI84TN+fMMlLKTdDPNnD/fPoAY6Bv3uFJOsl lvocpdF2hyBv
FNAceUpwJWRntW12GpGqtGut7eplgUNUSJ6vdfVi4mKfuzy3hvU8JgQ250Bm ahbV7wjevS07
mlI8q6DIK9HXKUt1eOEnWwvNbxI7mmoL09BFcdrdWAlC91m4I9M7CRSfNPjh F62NEAXifgTN
hYLy2aaidQj8qidk6NYF6Ch5eQxYGC+dBfEjhERYU6ZhmBfD5K3tXrVe2KHs CevXqucWTxqa
6B1Ig0r4Zq1rnLio613NlqZVzIkYOx8CVTpOU32vnsjSgXLPGirL/N4PtGYx ggOHMIIDgwIB
ATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5v
cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkq hkiG9w0BCQEW
EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBrx4MAkGBSsOAwIaBQCgggHbMBgGCSqG SIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNzA5MTQyMFowIwYJ KoZIhvcNAQkE
MRYEFE8rE/UTqdheroQ6JvZp0LeFTa2qMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEo
MIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0
cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcg QXV0aG9yaXR5
MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwa8eDCBkwYL KoZIhvcNAQkQ
AgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNl
cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEw HwYJKoZIhvcN
AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwa8eDANBgkqhkiG9w0BAQEFAASC AQAXv0MyPPVZ
ERX9uQEcLJPwhW48GgPGQvS6DnfRasc1JzN9n+pxCAOHoprdcPUWriLU9UnK NuKdHuInRvDT
zl4sfgAwtPi1X5MOplNcPE6u8YNeArkU9Vg1yPzJ4KiBJ4onaVVkAcAUOdTR Sdg7BCQk8DxE
T+21/EnzPmet2+K9p8XT4D66qTM5o1llbCDWntA1BhYkMTj3wKQAGtgxexvD zOnp1BQq2M2L
XihVp4VJnQo+oriLj0oBRVaSE40i8gWKaOk+/CDRAPH6MpAGB9Rs7+CpA8OD fXrE/ojA0jfd
9qOJv8TzWo2hF+M0P1gzTnUxREIa/wj4/m1XS5aNjT6oAAAAAAAA
--------------ms090408030308000501010609--

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

Hi thank you for looking at this,


SQLRowCount actually returns correct results,
and SQLMoreResults(hstmt)
returns SQL_NO_DATA which is also perfectly correct


So if I only comment out SQLMoreResults then
SQLFetchScroll works fine.

Therefore I am pretty certain that it is SQLMoreResults and
not SQLRowCount that cause a problem for pgODBC.

also there is no other way to get the number of rows
returned by select (of if it would be, it would certainly not
be ODBC compliant).

I emailed to Hiroshi in general about the row count, and
calling SQLMoreResults is the only way, otherwise I get
1 for bulk operations.


But going back to your question, SQLFetchScroll will error out
if you do not use select (because it is typically Select that returns
result rows).


Vlad







On Sun, 17 May 2009 11:14 +0200, "Christophe Garault"
wrote:
> Hello Vlad,
>
> I'm not sure that a call to SQLRowCount is allowed after a simple SELECT.
> What if you change your SELECT by an UPDATE or a DELETE ?
>
> --
> Christophe Garault
>
--
V S P
toreason@fastmail.fm

--
http://www.fastmail.fm - A fast, anti-spam email service.


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

This is a cryptographically signed message in MIME format.

--------------ms060009090103000804030202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Vlad,

V S P wrote :
> Therefore I am pretty certain that it is SQLMoreResults and
> not SQLRowCount that cause a problem for pgODBC.
>
Sorry I didn't pay enough attention to your code this morning.
And yes SQLMoreResults could be the cause of your problem: this function
is supposed to move to the next resultset !
So calling SQLFetchScroll after SQLMoreResults when having only one
resultset is not a good idea. Btw I'm not sure of what your code is
supposed to do...
Have a look at Ms's site if you want more information:
http://msdn.microsoft.com/en-us/library/ms714673(VS.85).aspx

> But going back to your question, SQLFetchScroll will error out
> if you do not use select (because it is typically Select that returns
> result rows).
Sure, I thought you were only interested in SQLRowCount.
A lack of caffeine on Sunday morning causes apologies. ;)

--
Christophe Garault

--------------ms060009090103000804030202
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIKhDCC
BT4wggMmoAMCAQICAwa8eDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdS b290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENl cnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9y ZzAeFw0wOTA0
MTYxNDIyMTRaFw0xMTA0MTYxNDIyMTRaMEQxGzAZBgNVBAMTEkNocmlzdG9w aGUgR2FyYXVs
dDElMCMGCSqGSIb3DQEJARYWY2hyaXN0b3BoZUBnYXJhdWx0Lm9yZzCCASIw DQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAOOQE63QCaPqEqjKbvivYkaI3nef9dos3tZS L6t+FY30WSdF
cf75Kg66whLwqd9hAmfldMDy5rXHjAHhApmNf/x5wdObBepclGbn4Vz49AEK bSjhZCRzydjr
zLqSgCp7TjUZETGGDlBjEi5VgB823qWt6IDq+EchtQFwlwPonrmywGn+Zs8V nO+iXwre3gb+
c9T65Z6AmcZFd7n0uBLuEqsNUGk+lwcam/tZHY2qjT2C5YiGKRh8zQdq4zIH F8FdHua8meUV
dttgC3gMk8fw1mACEZ2W1m/nL2/0gjIbaSoFqrBEy8Wzvf9ehoEb1pYlqxe2 4ij7NNXYAq5E
FhJnCb8CAwEAAaOCAQIwgf8wDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0
IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3
LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgME
BgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsG AQUFBzABhhZo
dHRwOi8vb2NzcC5jYWNlcnQub3JnMCEGA1UdEQQaMBiBFmNocmlzdG9waGVA Z2FyYXVsdC5v
cmcwDQYJKoZIhvcNAQEFBQADggIBAFvf2ZPck3MxbxfY0+epdQjr6g9ggN7m rLE5dZDvm0It
oCF0jImkGTeyz54qF/v5AVjtH9/AxvPe2zQS8jeU6GuQiaBAR/lKrJvh1pXq Yt1o3xM3h1wY
FVvQzghQT03crM9fbT7YwTIwKNQ+GcS7AaQ5Yjeiw1wHrUkW+4GfZ9PZg8wM 42XWrpzTUmeC
CimMFUhi58AQlEGEgjqlUj3Gz0xX9EZU8/EqfZX6F76UX+Vz1JtZnizgiiwd SNDS0OuaVY8f
bGBOnObMtm+Q5TTKy0rZ+PDjTYrCQj+bn0K1lJ9OjPzo4KiNLyTNOx8K9gLz GKL1gsRCOwmw
6A7a6yC/UYq/bDoPxRbvGu5RrCLsrhiPOEzfnzDJSyk3QzzZw/3z6AGOgb97 hSTrJZb6HKXR
docgbxTQHHlKcCVkZ7VtdhqRqrRrre3qZYFDVEier3X1YuJin7s8t4b1PCYE NudAZmoW1e8I
3r0tO5pSPKugyCvR1ylLdXjhJ1sLzW8SO5pqC9PQRXHa3VgJQvdZuCPTOwkU nzT44RetjRAF
4n4EzYWC8tmmonUI/KonZOjWBegoeXkMWBgvnQXxI4REWFOmYZgXw+St7V61 Xtih7Anr16rn
Fk8amugdSINK+Gata5y4qOtdzZamVcyJGDsfAlU6TlN9r57I0oFyzxoqy/ze D7RmMIIFPjCC
AyagAwIBAgIDBrx4MA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNV
BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4X DTA5MDQxNjE0
MjIxNFoXDTExMDQxNjE0MjIxNFowRDEbMBkGA1UEAxMSQ2hyaXN0b3BoZSBH YXJhdWx0MSUw
IwYJKoZIhvcNAQkBFhZjaHJpc3RvcGhlQGdhcmF1bHQub3JnMIIBIjANBgkq hkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA45ATrdAJo+oSqMpu+K9iRojed5/12ize1lIvq34V jfRZJ0Vx/vkq
DrrCEvCp32ECZ+V0wPLmtceMAeECmY1//HnB05sF6lyUZufhXPj0AQptKOFk JHPJ2OvMupKA
KntONRkRMYYOUGMSLlWAHzbepa3ogOr4RyG1AXCXA+ieubLAaf5mzxWc76Jf Ct7eBv5z1Prl
noCZxkV3ufS4Eu4Sqw1QaT6XBxqb+1kdjaqNPYLliIYpGHzNB2rjMgcXwV0e 5ryZ5RV222AL
eAyTx/DWYAIRnZbWb+cvb/SCMhtpKgWqsETLxbO9/16GgRvWliWrF7biKPs0 1dgCrkQWEmcJ
vwIDAQABo4IBAjCB/zAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6 Ly93d3cuQ0Fj
ZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB gjcKAwQGCisG
AQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH MAGGFmh0dHA6
Ly9vY3NwLmNhY2VydC5vcmcwIQYDVR0RBBowGIEWY2hyaXN0b3BoZUBnYXJh dWx0Lm9yZzAN
BgkqhkiG9w0BAQUFAAOCAgEAW9/Zk9yTczFvF9jT56l1COvqD2CA3uassTl1 kO+bQi2gIXSM
iaQZN7LPnioX+/kBWO0f38DG897bNBLyN5Toa5CJoEBH+Uqsm+HWlepi3Wjf EzeHXBgVW9DO
CFBPTdysz19tPtjBMjAo1D4ZxLsBpDliN6LDXAetSRb7gZ9n09mDzAzjZdau nNNSZ4IKKYwV
SGLnwBCUQYSCOqVSPcbPTFf0RlTz8Sp9lfoXvpRf5XPUm1meLOCKLB1I0NLQ 65pVjx9sYE6c
5sy2b5DlNMrLStn48ONNisJCP5ufQrWUn06M/OjgqI0vJM07Hwr2AvMYovWC xEI7CbDoDtrr
IL9Rir9sOg/FFu8a7lGsIuyuGI84TN+fMMlLKTdDPNnD/fPoAY6Bv3uFJOsl lvocpdF2hyBv
FNAceUpwJWRntW12GpGqtGut7eplgUNUSJ6vdfVi4mKfuzy3hvU8JgQ250Bm ahbV7wjevS07
mlI8q6DIK9HXKUt1eOEnWwvNbxI7mmoL09BFcdrdWAlC91m4I9M7CRSfNPjh F62NEAXifgTN
hYLy2aaidQj8qidk6NYF6Ch5eQxYGC+dBfEjhERYU6ZhmBfD5K3tXrVe2KHs CevXqucWTxqa
6B1Ig0r4Zq1rnLio613NlqZVzIkYOx8CVTpOU32vnsjSgXLPGirL/N4PtGYx ggOHMIIDgwIB
ATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5v
cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkq hkiG9w0BCQEW
EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBrx4MAkGBSsOAwIaBQCgggHbMBgGCSqG SIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNzE1NTM0MlowIwYJ KoZIhvcNAQkE
MRYEFO/0c7SFi8w3V5bs2NSqZMoRnoNzMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEo
MIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0
cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcg QXV0aG9yaXR5
MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwa8eDCBkwYL KoZIhvcNAQkQ
AgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNl
cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEw HwYJKoZIhvcN
AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwa8eDANBgkqhkiG9w0BAQEFAASC AQDJti46lQt9
6exy3/StJPszgt0qLv9gYA1rH3+ugyHV46FbiZkIDtvFojXhY6TeH27PhkJ1 +edSFw1KSjdF
Yf3Uz56VAvyEht6wtoOAy6HIU9p/woyk8wGu1hkqCf4/U9c+tFDwekrKLnBV rozhAoX8VMiQ
kcFjjeMikrQZvYvlq8tFZV1QTWytTb650advo9oJiP7UeZTL+HXv4xrHosgh P6vJvtNzzzVD
63w8RcItDraPQRYnuX2iAhfUn0Uf6C/3SGZHbhfAup4Nb5dSMgpqdGeWYRaP sxXaK8VoEly1
Ae1CfHoESe9wNNWfj9QrFy58uwcpCB2fCu1GSbYmsZ/ZAAAAAAAA
--------------ms060009090103000804030202--

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

Hi,
for some reason link does not work
but I did read yesterday abo0ut the SQLMoreResults

and as long as it returns
SQL_NO_DATA it means that it finished getting the results
and the MS website was saying that is the correct way to know
that no more data is there to be retreived.

While I do not have another ODBC driver to test with, I do not
see any reason why another ODBC driver would fail.


The goal for me is to be able to use a standard function to get
the number of rows affected by a given SQL operation

In practically all the ODBC drivers for any vendor
getting a result for a Bulk or single SQL statement is
simply calling SQLRowCount once is sufficient.

In more complex scenarios where a stored proc was involed that
could affect rows outise of the set that was passed in
SQLMoreResults and SQLRowCount in the loop is suggested at least for
MS SQL but not for DB2 ODBC or anybody else.

When I talked to Hiroshi he explained that for pgODBC even for
standard bulk operations I must use SQLRowCount+SQLMoreResults
in a loop -- or else it would not work (because PG native driver
does not support bulk operation so pgODBC simply calls generates
multiple single statements for the array data).

So I worked back and forth with OTL maintainer to implement this
functionality and pound define it (to use or not to use, because
some other odbc drivers did not like that pair ).


So we have put that functionality in OTL (to get the row count using
the pair) -- and now every single Select statement fails (workes
for inserts/deletes though because SQLFetchScroll is not called)

It fails with the error I outlined, so I went through the OTL
source debugging yesterday and created a sequence of ODBC statements
that cause the problem -- and that's how I created the test case.

It shows that row count using the pair of SQL statements does not work
with selects (because SQLFetchScroll is needed).

So that was the long version... since you asked.

So I am basically hoping to get pgODBC fixed (if this
is a bug) or a suggested workaround
how to get the row count in generic, oDBC compliant way (that is I
cannot have different ways for getting rowcount for different db
operations).


Vlad





On Sun, 17 May 2009 17:53 +0200, "Christophe Garault"
wrote:
> Hi Vlad,
>
> V S P wrote :
> > Therefore I am pretty certain that it is SQLMoreResults and
> > not SQLRowCount that cause a problem for pgODBC.
> >
> Sorry I didn't pay enough attention to your code this morning.
> And yes SQLMoreResults could be the cause of your problem: this function
> is supposed to move to the next resultset !
> So calling SQLFetchScroll after SQLMoreResults when having only one
> resultset is not a good idea. Btw I'm not sure of what your code is
> supposed to do...
> Have a look at Ms's site if you want more information:
> http://msdn.microsoft.com/en-us/library/ms714673(VS.85).aspx
>
> > But going back to your question, SQLFetchScroll will error out
> > if you do not use select (because it is typically Select that returns
> > result rows).
> Sure, I thought you were only interested in SQLRowCount.
> A lack of caffeine on Sunday morning causes apologies. ;)
>
> --
> Christophe Garault
--
V S P
toreason@fastmail.fm

--
http://www.fastmail.fm - Email service worth paying for. Try it for free


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

V S P wrote:
> Sorry forgot to mention the actual error I am getting:
>
> http://pastebin.com/d49e830c0
>
> SQLSTATE = HY010
> NATIVE ERROR = 0
> MSG = [Microsoft][ODBC Driver Manager] Function sequence error

Please do fetch operations for each result. For exmaple you
can do fetch operations at *// Do fetch operations here *
below.

regards,
Hiroshi Inoue

174./******************************************************* ****/
175./* PROBLEM: */
176./* IF YOU COMMENT THE BELOW LOOP OUT SQLFetchScroll works */
177./******************************************************* ****/
178.
179. do
180. {
181. rc = SQLRowCount(hstmt, &rpc);
182. if (rc!=SQL_SUCCESS)
183. {
184. break;
185. }
186. rowsum += rpc;

// Do fetch operations here

187. rc = SQLMoreResults(hstmt);
188. } while (rc==SQL_SUCCESS);



--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [Q] SQLMoreResults causes error in SQLFetchScroll

Hi
thank you,

unfortunately there is no way to do that (as the OTL library
relies on RowCount to be an independent function
and it cannot be mixed with other operations

(because then getting row count for Insert/Delete/Update would
require a completely different function flow then for selects)

So cannot even suggest OTL maintainer to implement this, as there
is no feasable way.

Is this an expected behavior (that is an ODBC spec recommends this)?


thank you,
Vlad


On Mon, 18 May 2009 12:27 +0900, "Hiroshi Inoue"
wrote:
> V S P wrote:
> > Sorry forgot to mention the actual error I am getting:
> >
> > http://pastebin.com/d49e830c0
> >
> > SQLSTATE = HY010
> > NATIVE ERROR = 0
> > MSG = [Microsoft][ODBC Driver Manager] Function sequence error
>
> Please do fetch operations for each result. For exmaple you
> can do fetch operations at *// Do fetch operations here *
> below.
>
> regards,
> Hiroshi Inoue
>
> 174./******************************************************* ****/
> 175./* PROBLEM: */
> 176./* IF YOU COMMENT THE BELOW LOOP OUT SQLFetchScroll works */
> 177./******************************************************* ****/
> 178.
> 179. do
> 180. {
> 181. rc = SQLRowCount(hstmt, &rpc);
> 182. if (rc!=SQL_SUCCESS)
> 183. {
> 184. break;
> 185. }
> 186. rowsum += rpc;
>
> // Do fetch operations here
>
> 187. rc = SQLMoreResults(hstmt);
> 188. } while (rc==SQL_SUCCESS);
>
>
--
V S P
toreason@fastmail.fm

--
http://www.fastmail.fm - Accessible with your email software
or over the web


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc