Antonio,
It seems that in usrrdd.c are missing some functions like FieldSize FieldLen Dbrlocklist.
Shouldnt these also be there?
Regards
Antonio H Ferreira
Antonio H Ferreira
Board index FiveWin for Harbour/xHarbour ADO RDD xHarbour
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 (1047 posts)
AHF wrote:Antonio,
What this needed for:
STATIC FUNCTION ADO_RAWLOCK( nWA, nAction, nRecNo ) // LOCAL oRecordSet := USRRDD_AREADATA( nWA )[ WA_RECORDSET ] /* TODO */ HB_SYMBOL_UNUSED( nRecNo ) HB_SYMBOL_UNUSED( nWA ) HB_SYMBOL_UNUSED( nAction ) RETURN HB_SUCCESS
It does nothing but it is needed. In case that you need it to do something, then you can implement it.
Antonio,
You should download the complete source code for the harbour RDDs and use it to review the RDD code:
https://github.com/harbour/core/tree/master/src/rdd
You should download the complete source code for the harbour RDDs and use it to review the RDD code:
https://github.com/harbour/core/tree/master/src/rdd
Antonio,
I dont have any c expert and even so it would be dificult to understand it without proper documentation.
In order to proceed I need the following functions working:
OrdFor()
FieldSize() or FieldLen()
FieldDec()
DbrlockList()
I'm in a dead end ! What do you propose?
Regards
Antonio H Ferreira
Antonio H Ferreira
Antonio,
Its not a matter of knowing C, instead it is a matter of properly searching 
You asked for OrdFor().
- Is there a UR_FOR or similar in harbour\include\hbusrrdd.ch ?
I find this:
/ DBSCOPEINFO /
define UR_SI_BFOR 1
define UR_SI_CFOR 2
Also:
/ DBORDERCONDINFO /
define UR_ORC_ACTIVE 1
define UR_ORC_CFOR 2
-
Have we implemented those functions in adordd.prg ?
-
In SQL we may need to store a string cFor value only, no need for the codeblock.
I know this is not easy, but slowly we can keep going...
Antonio,
As far as I see no.
Its absolutly necessary to build the selects respecting indexes order and conditions.
If the index is created (temporary) then on ADO_CREATE we have all info we just save it for later use.
If the index its usual then it must be defined previously in the index array.
So the problem its only with ordfor() to get the values saved.
What do you mean by those functions ?
I can have such a function(s) but then I will disrupt other linked rdds, besides that since we dont have nWA we can not use it like (alias)->(ordfor(2))
I think all mentioned functions must be defined at rdd level to be used correctly as they probably are in dbfcdx rdd for ex.
The adordd its working already with "indexes" with zero app code change and if you get an error you will have all area info.
Dont get me wrong its not a matter of difficulty but if its in fact possible to work with our approach idea and that we are not simply loosing time as we are trying to join together two completly diferent worlds xBase and SQL.
Besides that we have till June to have such a solution.
Is there some rdd expert that could help us? How can we solve this? Can you check how its working in other rdds?
1. Is there a UR_FOR or similar in harbour\include\hbusrrdd.ch ?
As far as I see no.
3. In SQL we may need to store a string cFor value only, no need for the codeblock.
Its absolutly necessary to build the selects respecting indexes order and conditions.
If the index is created (temporary) then on ADO_CREATE we have all info we just save it for later use.
If the index its usual then it must be defined previously in the index array.
So the problem its only with ordfor() to get the values saved.
2. Have we implemented those functions in adordd.prg ?
What do you mean by those functions ?
I can have such a function(s) but then I will disrupt other linked rdds, besides that since we dont have nWA we can not use it like (alias)->(ordfor(2))
FUNCTION OrdFor(nOrder)
//works only for current selected workarea not alias->(ordfor(n))
LOCAL cTablename := USRRDD_AREADATA( Select() )[ WA_TABLENAME ]
LOCAL aWAData := USRRDD_AREADATA( Select() )
LOCAL cFor := ""
IF nOrder = 0
nOrder := aWAData[WA_INDEXACTIVE]
cFor := aWAData[WA_INDEXFOR][nOrder]
ELSEIF nOrder <= LEN(aWAData[WA_INDEXES] )
cFor := aWAData[WA_INDEXFOR][nOrder]
ENDIF
RETURN cForI think all mentioned functions must be defined at rdd level to be used correctly as they probably are in dbfcdx rdd for ex.
The adordd its working already with "indexes" with zero app code change and if you get an error you will have all area info.
20: ENCCLIST NomeRDD: ADORDD
==============================
RecNo RecCount BOF EOF
1 34 .F. .F.
Índices em uso TagName
=> NRENCOMEND+CODIGOPROD+ARMAZEM ENCCPRO
CODIGOPROD+ARMAZEM+NRENCOMEND PROENCC
GUIA+CODCLIENTE+CODIGOPROD+ARMAZEM MECPD
CODCLIENTE CDENCCL
NRFACTUR+CODCLIENTE+CODIGOPROD+ARMA PTFACT
NRFACTUR+CODIGOPROD+ARMAZEM+ANO +SE NRFPROD
CODIGOPROD+NRCONTRATO CCONTRT
Relações em uso
Registos fechados
30: => OFERTAS NomeRDD: ADORDD
==============================
RecNo RecCount BOF EOF
1 3 .F. .F.
Índices em uso TagName
CODCLIENTE+CODIGOPROD+ARMAZEM+DATAO CLIPRO
CODIGOPROD+ARMAZEM+CODCLIENTE+DATAO PROCLI
CODCLIENTE+DATAOFERTA +NUMEROOFER+C CLIPRO2
CODIGOPROD+ARMAZEM+DATAOFERTA +NUME PROCLI2
=> CODCLIENTE TEMP2
Relações em uso
Registos fechadosDont get me wrong its not a matter of difficulty but if its in fact possible to work with our approach idea and that we are not simply loosing time as we are trying to join together two completly diferent worlds xBase and SQL.
Besides that we have till June to have such a solution.
Is there some rdd expert that could help us? How can we solve this? Can you check how its working in other rdds?
Regards
Antonio H Ferreira
Antonio H Ferreira
Antonio,
I never looked at .ch.
I understand now how it works.
Ive define UR_INFO and now I get the call from dbrlocklist do get the array.
We re back again
Regards
Antonio H Ferreira
Antonio H Ferreira
Antonio,
Very good!
Antonio,
if you post here or provide a url to download your most recent version, I guess many users may be interested
in testing it and surely will provide a great feedback
Antonio,
Ill do that maybe today after finish all locking, seeks and finds.
Dbrlocklist() and Dbinfo() are working
.
Ive checked the paramaters in hbusrdd.c
Can I assume that when we have pSomeVar its always a pointer thus passed by reference?
Thus in this case ADO_ORDERINFO(nWa, nInfo, uReturn) uReturn passed reference
The Recno() only works with :Bookmarks as:
The commented line was in previous adordd but I think its safer like this. Do you agree?
Ill do that maybe today after finish all locking, seeks and finds.
Dbrlocklist() and Dbinfo() are working
.
Ive checked the paramaters in hbusrdd.c
hb_usrInfo( AREAP pArea, HB_USHORT uiInfoType, PHB_ITEM pInfo )Can I assume that when we have pSomeVar its always a pointer thus passed by reference?
Thus in this case ADO_ORDERINFO(nWa, nInfo, uReturn) uReturn passed reference
The Recno() only works with :Bookmarks as:
nRecno := oRecordSet:BookMark
// iif( oRecordSet:AbsolutePosition == -3, oRecordSet:RecordCount() + 1, oRecordSet:AbsolutePosition )The commented line was in previous adordd but I think its safer like this. Do you agree?
Regards
Antonio H Ferreira
Antonio H Ferreira
Antonio,
yes I think it is fine.
You are doing a great work, congratulations!
Once you complete it, you could provide it to Harbour dev team so it will get updated in the Harbour official repository
and you will become an official Harbour contributor
Antonio,
In order to finish network and concurrent activity I need to work with transactions.
For that I need to know if in ADORDD each time we open a new recordset its in the same connection.
Its crucial to know this because transactions are per connection.
Do you have any idea how to test that?
Regards
Antonio H Ferreira
Antonio H Ferreira
Antonio,
AS far as I know I would say yes, but Mr. Rao is the right one to confirm us this
Antonio,
Ive already ask him in my oyher post ADO exclusive open.
It seems that in the source of tdatarow we could check that.
Regards
Antonio H Ferreira
Antonio H Ferreira