ADO RDD xHarbour

[AHF]

Lucas,

Please remember:
hb_adoSetLocateFor is needed as LOCATE calls in adordd:

ADO_SETLOCATE( nWA, aScopeInfo )
ADO_LOCATE( nWA, lContinue )

Unfortunately aScopeInfo doesnt supply the cFor condition only bFor condition thus we need to set it up before with hb_adoSetLocateFor.

Let me check what we can do.

[lucasdebeltran]

Antonio,

Thnak you for your attention.

At least, it should support LOCATE FOR Upper(FIELD->City) = Upper(cCity).

[AHF]

Lucas,

I ve just recheck it and I dont see any other alternative.

You have to consider :

LOCATE FOR Upper(FIELD->City) = Upper(cCity).

This s passed to ADO_SETLOCATE in aScopeInfo as a code block.
We need hb_adoSetLocateFor to have it as a string.

But another problem is the hb_adoSetLocateFor( <(for)> ) (adordd.ch) needs to receive it as a string:

" Upper(FIELD->City) = Upper(cCity)"

This cant be evaluated because the variables are out of scope at ado framework.
This we must sent as for other rdds like ADS with the value of that var and not the var itself thus you will have to do:

"Upper(FIELD->City) ="+"'"+ Upper(cCity)+"'"

Then the string would be:

Upper(FIELD->City) ='LONDON'

The same will happen in index expressions with vars.

Sorry there isnt any other way.

For us no problem because the app worked already with ADS and it was already doing that.

Nevertheless this should not be a problem because its a very fast change in the app code and does not break any logic of it that's why I proposed the foloowing way of change it:

IF RDDSNAME() = "ADORDD"
//NEW EXPRESSIONS FOR ADO
ELSE
//AS ALREADY WRITTEN CODE
ENDIF

[AHF]

Antonio, Mr Rao,

Im having a problem with Numeric fields Len and Dec.

Solved !

[AHF]

Lucas,

Locate works now exactly the same as for dbfcdx and others. No need to alter anything in the code.
I choose to eval(bBlock) in do while performance its almost the same as with find.

Ill post new version today.

[lucasdebeltran]

Antonio,

Did you really fixed LOCATE FOR... command?.

That´s a great news!.

Also, there is a mistake on this line:

FUNCTION ADO_OPEN( nWA, aOpenInfo )

oRecordSet:Fields( aWAData[WA_FIELDRECNO] ):Properties("Optimize") := 1


Thank you.

[AHF]

Lucas,

Im still solving some problem with LOCATE .

Code: Select all  Expand view

oRecordSet:Fields( aWAData[WA_FIELDRECNO] ):Properties("Optimize") := 1

What is the mistake ? Compile ? With xHarbour ok.

[lucasdebeltran]

Antonio,

It says:

adordd\adordd.prg(278) Error E0022 Invalid lvalue ':'

[AHF]

Lucas,

I have no idea why that error. Here its ok. Is that a compile error?

I posted new adordd.prg and .ch with LOCATE ready. https://github.com/AHFERREIRA/adordd.git

Now you dont need to alter anything
I have some funny problem here but I dont know if it is caused by new LOCATE.

Please check it yourself.

[lucasdebeltran]

Antonio,

Thank you.

What sort of new problems did you find?.

[nageswaragunupudi]

I am moving our disucssions to this thread to keep them at one main place.
You said:

(ownd:numera)->dataultmov is 28/04/15
dDataM is 28/04/15

if (ownd:numera)->dataultmov > dDataM

msginfo("Data do ult doc "+dtoc((ownd:numera)->dataultmov)+CRLF+;
"Data deste doc "+dtoc(dDataM) )

endif

The code inside the IF should never be executed but it is and the msginfo shows both with the same date 28.04.15.

What might be the reason?

First recommended caution is to keep always Century on.

Most date fields in various SQL servers store acutally date-time values, not pure truncated date values. Please keep in mind that I said "most" not "all".

If for some reasons, the value stored in the field is 28/04/2015 00:00:00.001 then this field value is greater than pure date 28/04/2015. Years back I struggled till I found that xHarbour was adding one extra milli second. ( I do not know if this is ok now)


We need to be extra-cautious while dealing with dates in sql databases. For the purpose of ADORDD, please return truncated date ( with valtype 'D') when the FieldType is "D" and full value with valtype 'T' when the field type is 'T'.

I suggest you return FW_TTOD( <fieldvalue> ) when the FieldType is 'D' and FW_DTOT( <fieldvalue> ) when the field value is 'T'. We use this in our XBrowse, TDataRow and TRecSet so that users are insulated from this behavior.

We need to keep this in mind when preparing SQL statements comparing Dates.
For example, SELECT * WHERE INVDT BETWEEN '2015-04-01' AND '2015-04-30' may totally exclude all transactions that took place on 30th Apr 2015. Because this is actually translated as INVDT >= '2015-04-01 00:00:00' and INVDT <= '2015-04-30 00:00:00'. Naturally this query ignores transactions from '2015-04-30 00:00:00.001' till '2015-04-30 23:59:59.999'
This is just an example to show how deceptive can be date comparisons. In addition MS Sql server has a very awkward habit of storing '2014-04-01' internally as '2014-04-01 12:00:00' in the field.
So, the safer construct is SELECT * WHERE INVDT >= '2015-04-01' AND INVDT < '2015-05-01'. I still see many amatuers committing this mistake which turns out to be a blunder in real life situations.

I hope if you keep this points in mind, everything will work as expected.

[nageswaragunupudi]

You said in the other thread.

I´ve tested it and it works perfectly with adUseclient and adUserServer cursors.

Glad to know it is working well with both client and server-side.

Please see for reference:
https://msdn.microsoft.com/en-us/librar ... 8(v=bts.10).aspx
"https://msdn.microsoft.com/en-us/library/ee252458(v=bts.10).aspx"


Extracts:

adLockPessimistic 2 This value indicates pessimistic locking, record by record. The provider does what is necessary to ensure successful editing of the records, usually by locking records at the data source immediately after editing.
This lock type is supported by the Microsoft® OLE DB Provider for AS/400 and VSAM and the Microsoft OLE DB Provider for DB2. However, the OLE DB Provider for AS/400 and VSAM internally maps this lock type to adLockBatchOptimistic.

and

The adLockPessimistic setting is not supported if the CursorLocation property is set to adUseClient. If an unsupported value is set, then no error will result; the closest supported LockType will be used instead.

You said:

So we never call :Update() in ADO_PUTVALUE and ADO_APPEND and the :Update is then called only ADO_UNLOCK. Right?

Good Idea.

The app Im converting gets all the new records an locks and then goes through the Locklist array of each table processing each replace.
Since we move the record we lost the physical lock right?

Yes.
It appears multi-record locking does not seem possible in ADO. Anyway you need to keep experimenting more on this, simultaneously working as two users on the same table.

Starting a transaction can eliminate this ?

Transactions and locking are two different things altogether.
All updates within one transaction block either they get written or abandoned but never written partially. Normally used for multi-table updataions with the same connection.

Talking about transactions, they work for a single connection. If we open recordsets with connection string each of them will get a separate connection.

[AHF]

I suggest you return FW_TTOD( <fieldvalue> ) when the FieldType is 'D' and FW_DTOT( <fieldvalue> ) when the field value is 'T'. We use this in our XBrowse, TDataRow and TRecSet so that users are insulated from this behavior.

I dont have these functions. Can you post them here?

So, the safer construct is SELECT * WHERE INVDT >= '2015-04-01' AND INVDT < '2015-05-01'. I still see many amatuers committing this mistake which turns out to be a blunder in real life situations.

To avoid apps code change then we could do it:

SELECT * WHERE INVDT BETWEEN '2015-04-01'+'00:00:00:000' AND '2015-04-30'+'23:59:59.999'

adding the time part to the date at adordd.
Resuming we always add at adordd the time part of the date like that. Right?

Thanks so much for your help and expertise.

[AHF]

Glad to know it is working well with both client and server-side.

It works in the sense of the locking (with 2 users the 2nd cannot edit) but changing order focus we build a new recordset with the order by clause and closing the current one throws an error.
Also if we get the locks and move to other records we loose it.

I think the only alternative is to have another field or a table to do it but we still didn't find how.
Do you have any idea?

Also using adUseclient seems not to work ok with our browses. adUseServer ok.
But adUseServer doesnt work with Browse() in ACCESS.
Dont know why.

[AHF]

Antonio,

Thank you.

What sort of new problems did you find?.

Please check ADO_LOCATE.
If we call successive locates although it goes through the records correctly in the do while it does not evaluate the block to .t. after the first time.

Please try:

Code: Select all  Expand view

do while n < 20
    locate for whateverfield = whatevervalue // existing in the table
    if found()
       msginfo("found()")
   else
       msginfo("not found()")
   endif
    n++
enddo
 

Now if you place a browse() just after locate it goes ok.
Can you see it?

We are looking for a explanation.

Antonio, Mr Rao, do you have some clue?