ADOmate - use OLE-DB datasources via ADO - (BLOBs added)

[srod]

Kiki,

you don't need to send me a pm and post here! One or the other will do.

Anyhow, you will need to give me far more details if you wish me to take a look at this. Which ADOmate method is causing the problem? Can I see your code? I may need a copy of the database in question.

[srod]

@KIKI : Right, it is not a bug. There was a bug in the old version of ADOmate which prevented this 'error' from being reported.

What is happening is that the fields causing the 'problem' contain null values. COMatePLUS is reporting this as a type mis-match because it of course tries to convert them to strings (or integers if you use ADOmate_GetDatabaseLong() etc.)

So, don't worry about it. You can still retrieve these null fields as per normal and you will just get an empty string etc. There is no danger of a crash. I will not 'fix' COMatePLUS because it could be handy to keep this detection of null fields intact.


@ALL :
However, I have found (and fixed) a huge problem with ADOmate 2.0.2 and so you will need to download ADOmate 2.0.3 from the nxSoftware site. The bug will cause problems with queries returning multiple rows or rows in which there are some null fields.

[ABBKlaus]

As kiki reported there is a bug within ADOmate.

The following commands could fail because they rely upon COMate_GetLastErrorCode() :

Code: Select all

ADOmate_DatabaseColumnType()
ADOmate_DatabaseColumnSize()
ADOmate_DatabaseColumnName()

Code: Select all

Procedure.s ADOmate_DatabaseColumnName(*connection._ADOmateConnection, column)
  Protected error, result$
  If *connection
    If *connection\recordsetObject
      If COMate_GetLastErrorCode() = #S_OK ; <- bug !
        If column>=0 And column < *connection\numColumns

BR Klaus

[srod]

No, that's not the problem reported by Kiki, although this did cause certain problems which were apparent with the database Kiki sent me. This is actually part of the bug I reported in my previous post and thought I'd fixed! I thought I had removed all of those extraneous calls which have been left over from ADOmate 2.0.1, but obviously not!

I shall upload version 2.0.4 in a few minutes.

Thanks.

[ABBKlaus]

If i understand correctly COMate is reporting a 'NULL' field as error ?

[srod]

Yes, but it will not impact upon your ability to retrieve such fields (you will just receive an empty string etc.) If you query for an error immediately after retrieving a null field then you will obtain a 'type mismatch' error resulting from COMatePLUS's use of VariantChangeType_().

I can easily change this if required.

[ABBKlaus]

Thanks for explanation, it works now

I would consider using a separate error for a null field or a special command like ADOmate_IsNull() ?

[EDIT] BTW, i noticed that for binary returns i get 0 for false and -1 for true, is that on purpose ? [/EDIT]
(I mean its not the same as the PB command is retrieving for the same type of column)

Thats why i´m modifying some commands in ADOmate :

Code: Select all

ADOmate_GetDatabaseLong()
ADOmate_GetDatabaseLongByFieldName()
ADOmate_GetDatabaseString()
ADOmate_GetDatabaseStringByFieldName()

To something like this :

Code: Select all

Procedure.l ADOmate_GetDatabaseLong(*connection._ADOmateConnection, column)
  Protected result.l, error, ColumnType
  If *connection
    If *connection\recordsetObject
      If column>=0 And column < *connection\numColumns
        *connection\column = column
        ColumnType = *connection\recordsetObject\GetIntegerProperty("Fields(" + Str(column) + ")\Type")
        If ColumnType = #adBoolean
          result = *connection\recordsetObject\GetIntegerProperty("Fields(" + Str(column) + ")\Value", *connection\hStatementRetrieve)&1
        Else
          result = *connection\recordsetObject\GetIntegerProperty("Fields(" + Str(column) + ")\Value", *connection\hStatementRetrieve)
        EndIf
        If comate_GetLastErrorCode() = #S_OK
          error = #ADOmate_OKAY
        Else
          error = #ADOmate_COMateERROR
        EndIf
      Else
        error = #ADOmate_ARGUMENTOUTOFRANGE
      EndIf
    Else
      error = #ADOmate_NOQUERYDEFINED
    EndIf
  Else
    error = #ADOmate_INVALIDARGUMENT
  EndIf
  CompilerIf Defined(ADOmate_NOERRORREPORTINGDURINGRECORDRETRIEVAL, #PB_Constant)=0
    ADOmate_SetError(error)
  CompilerEndIf
  ProcedureReturn result
EndProcedure

BR Klaus

[srod]

I would have thought that Boolean True would have equated to -1 and False to 0! I think you must be wrong.

I will not make any such modifications to ADOmate, however, because the additional invokation of a COMatePLUS method will not be welcome and is of no use to me. Incdientally, you will want to remove the *connection\hStatementRetrieve from the columnType = ... row as this particular statement is invalid for retrieving the column type.

**EDIT : just tested a YESNO column with an mdb file and TRUE is returned as -1 and FALSE equates to zero which makes sense (#VARIANT_TRUE and #VARIANT_FALSE). In fact, your own modification contradicts what you have said because your modification will only work if FALSE does indeed equate to 0!

No, there is no need to modify ADOmate.

[ABBKlaus]

ups corrected my above post. You are totally right (ADO)true equates to -1 (#VARIANT_TRUE) and false to 0 (#VARIANT_FALSE) !

Incdientally, you will want to remove the *connection\hStatementRetrieve from the columnType = ... row as this particular statement is invalid for retrieving the column type.

Thanks for your answer, you have enlightened my mind.

No, there is no need to modify ADOmate.

To avoid that other people fall for it you could mention the bool datatype in the help file to return #VARIANT_TRUE (-1) instead of PB´s #True (1)

BR Klaus

[srod]

Well, the reason I didn't consider a ADOmate_GetDatabaseBoolean() function was first that since COMatePLUS offers no such method (\GetBooleanProperty()), such a function would simply make use of ADOmate_GetDatabaseLong() etc. and I saw no point in wrapping this for the sole purpose of retrieving a boolean value.

The second reason... consider the fact that ADOmate has been around for nearly 2 years and that you are the first to enquire about boolean fields!

[srod]

2nd September 2010.

Please download ADOmate 2 again... I inadvertently failed to apply the previously mentioned 'speed increase' (COMatePLUS prepared statements) to ADOmate_GetDatabaseString(). Doh!!! I wondered why it was taking a long time to retrieve a bunch of records?

[DoubleDutch]

Has anyone got AdoMate and ComMate (ComMatePlus???) as the dload links are dead now..

[ts-soft]

Has anyone got AdoMate and ComMate (ComMatePlus???) as the dload links are dead now..

http://dl.dropbox.com/u/3086026/ADOmate.zip
http://dl.dropbox.com/u/3086026/ComatePLUS.zip

Greetings -Thomas

PS: this links only temporary!

[DoubleDutch]

Thanks very much.

[coelhorb]

Please could you put ADOmate link available again? http://dl.dropbox.com/u/3086026/ADOmate.zip doesn't work any more and I can't find it anywhere on internet. The nxsoftware's site is out. Thanks and sorry for my poor english.