New Harbour 3.2 incompatibility with Win_Ole ADO

332 views
Skip to first unread message

David Field

unread,
Jan 26, 2018, 2:47:41 AM1/26/18
to Harbour Developers
Hello,

I have been using up to today Harbour 32 version dated 2016-11-16 according to last log made in changelog.txt

Today I decided to update to Harbour 3.2 version 2017-08-13 according to the last log made in changelog.txt

I use ADO with function win_oleCreateObject( "ADODB.Recordset" )

On 2016 version I get correct result from ADO Recordset method GetRows() = one array with all fields for each record within an array
I have a table with 23 fields and only 1 record.

with previous harbour version I get correct result
oRs := win_oleCreateObject( "ADODB.Recordset" )
oRs:Open(...)
aRecords := oRs:GetRows()
? LEN(aRecords)       ==> 1 item
? LEN(aRecords[1])    ==> 23 items

With new version of harbour incorrect result
? LEN(aRecords)       ==> 23 items
? LEN(aRecords[1])    ==> 1 item

How is this possible?
GetRows method is from Win_OLE...???

Any sugestions, help?
Is this an error in new harbour version?

Thanks,
David Field

ToninhoFWi

unread,
Jan 26, 2018, 9:25:04 AM1/26/18
to harbou...@googlegroups.com

Maybe this change:

2017-07-03 18:36 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
  * contrib/hbwin/olecore.c
    ! reverted order of indexes and dimensions in conversions of
      multidimensional arrays.
      This modification affects both conversions (1) from Harbour array
      to OLE variant SafeArray and (2) from OLE variant SafeArray to Harbour
      array. The first one is new Harbour extension of __oleVariantNew() so
      here above modification should not create any backward compatibility
      problems but the second interacts with code which existed in Harbour
      from early OLE implementation so if someone already encoded hacks
      to revert array indexes and dimensions at .prg level then now he has
      to remove it.
      Please not that above modification affects only for multidimensional
      OLE typed arrays. It does not change anything for single dimension
      arrays or single dimension arrays of variants which contains other
      similar arrays in their items.
--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Field

unread,
Jan 26, 2018, 5:57:55 PM1/26/18
to Harbour Developers
Hello,

I dont quite understand what this means.

I have not encoded hacks to harbour.
Is harbour now taking decisions on how other software should work?

Does this mean I will not be able to use ADO or other OLE that return or work with multidimensional arrays?

Please let me know if this will remain this way or there will be a fix so that I can take appropriate action.

Thanks,
David Field

Aleksander Czajczynski

unread,
Jan 27, 2018, 3:45:44 AM1/27/18
to harbou...@googlegroups.com

> Em 25/01/2018 22:16, David Field escreveu:
>> Hello,
>>
>> I have been using up to today Harbour 32 version dated 2016-11-16
>> according to last log made in changelog.txt
>> [...]

>>
>> I have a table with 23 fields and only 1 record.
>> Any sugestions, help?
>> Is this an error in new harbour version?
Documentation to ADO API -
https://docs.microsoft.com/en-us/sql/ado/reference/ado-api/getrows-method-ado

"Remarks
Use the GetRows method to copy records from a Recordset into a
two-dimensional array. The first subscript identifies the field and the
second identifies the record number. "

I think current harbour behaviour is now on par with ADO documentation.
ADO uses typed arrays for the field values, each field is assumed to be
the same type, that's why it's field[recno] relation. This in fact may
feel less logical for xBase programmer, but GetRows() just returns what
ADO API returns, and the previous "2016" Harbour output was opposite to
the docs...

Best regards, Aleksander Czajczynski


David Field

unread,
Feb 2, 2018, 8:03:39 PM2/2/18
to Harbour Developers
Aleksander,

You are correct, and I am thinking as an xBase programmer.
It was so easy before... (snif), now I have to redo as before.

Thanks,
David Field
Reply all
Reply to author
Forward
0 new messages