FiveTech Software tech support forums

Otto,

When I first started working with Harbour/xHarbour (.com ), the options were RDDCDX, Apollo, and ADS. I received a lot of input and elected to use ADS. They publish an excellent White Paper that made a lot of sense to me. For small installs, we can use ADS local and its free. However, I have clients with poorly behaving equipment ( not well maintained, subjected often to malware by the users, etc ), and ADS seemed to be a good safety alternative. So all of my larger installs are told to consider ADS.

Many of my clients exceed 5 workstations. I don't want to play with configuring their systems, and ADS is quick and easy to install. I tell people to start with the Peer to Peer ( LOCAL ), but when they don't like the performance, I give them a 30 day free trial of ADS. No one complains about the price after they see the performance improvement. For example, in an invoicing section, the program opens six .dbf files, with .fpt's and .cdx's, in a filtered mode. WIth peer to peer, this can be slow. With ADS its instantaneous. Since that is the area they spend the most time in each day, they see the performance boost.

My issue had to do with a resellers account. My account renews in June, and I was one sale short of a free status. Of course that may change before my anniversary date, but they were talking a stiff charge which I was unwilling to pay. That has since been resolved. Other then that issue, I have no problem with ADS.

I do have clients with up to 18 workstations, networked across multiple worksites.

The cost is relative. My clients might not want to pay the expense, but they can afford it. They just would rather spend the money outside of their business needs ! Also, it can be a one time cost. I have people who spent $ 650 US 8 years ago, for a 5 user license, and they have never upgraded it. They still use it to this day. Thats pretty cheap for a business.

You have done some very nice work with your product, and have found a multi-user option that fits your clients. I appreciate that work. However, I just didn't see it as the right solution for my clients.

Tim

Reinaldo,

Please, try to use link provided.

It uses twbrowse.

Arc browser is different.

Yes, datas appear!!. But very slowly.

I think it is a point that Sybase could improve.

Best regards

"...the fact that xbrowse is terrible with ADS RDDs, even with the Local and/or Remote servers and not just AIS."

Reinaldo,

Could you explain ? I have not been using AIS ( issues with my ISP for testing ) but I do use ADS server ( REMOTE ) mode and my xbrowse implementations are all working quite quickly ( I guess thats a "real world" analysis based on what users are actually doing ). I do have some filters in place ( scopes, actually ), and I do use indexed browses, but I have no problems with xbrowse performance in a networked environment.

Perhaps you could clarify this statement.

Tim

Lucas;

Ok. I just did. Whaoo, it is more than 100 times slower than with ARC. Try with ARC32 you will see it is 100 times faster than the supplied app on the .zip file.

The question is; why? It is the same AIS (server side), same server (linux, windows, novell? -doesn't matter), same internet connection, same tables, same records. The only thing that's different is the fw component vs a Delphi grid component.

We need to compare browsing speeds using the same components over the same connections to the same server where the only variable changing is the SQL engine itself. Doing this homework requires time and effort as well as knowledge on both technologies.

Before bringing this issue to Sybase R+D, we should be prepared to demonstrate that the problem is not xharbour/fw or our components, otherwise we are going to look like fools and they may never take us seriously. Keep in mind they have millions of users using Delphi, .net, php, Java, Pyton, oData web services, and other. AIS speed is not an issue for these users or at least non of them is complaining.

Perhaps we should start by stating a DB schema, then have the tables populated with the same data. Then start testing using the same server. Anyone says "I" ?


Reinaldo.

Tim;

Yes, good question. The problem is not always manifested as it takes a given set of circumstances such as alternate row painting (pijama effect), table size, etc...

Here is a link to that subject as stated by Mr. Rao:

viewtopic.php?f=3&t=9343&hilit=why+are+slow+ADS

Reinaldo.

Several years ago, I followed the suggestions and used scopes rather than filters for my xbrowses. Maybe that is why everything works well.

Tim

Reinaldo,

Thank you very much for your advice and comments.

I will test, because if I solve the problem with xBrowse, ADS will be the right choice.

It is also strange as Rene´s sample is build with tbrowse, which is faster than xBrowse.

Maybe Mr. Nages could help us.

Timm,

Do you use xbrowses with AIS over Internet or just in LANS?.

In LANS they work fast, yes. And filters.

I want to use them on the internet, but right now I have a server issue ( IP ). I will be exploring this soon.

Tim

Hola a todos,

let me give some opinions about speed.

When we use ADO we maintain a data set locally, then this is faster that traditional Harbour RDD approach.

Other question about ARC vs. xBrowse, the problem is the xBrowse implementation, it refresh all the data many times for every event, it retrieve the same data showed in the page for every move event, maybe we can improve it adding caching capabilities

sorry for may good english

Regards

Marcelo

Reinaldo,

This is the code i am using:

Code: Select all  Expand view

function Test_SQL()

   LOCAL cSql   := ""
   LOCAL aArray := {}

   LOCAL cAlias := Alias()




   /*al inicio de la instruccion sql se define un area vacia*/
   DBSelectArea(0)


   /*se define instruccion sql en una cadena de texto*/
   cSql := "SELECT * FROM CUSTOMER"
   msgINFO(csql, "cSql")


   /*crea instruccion sql y pasa los datos a tabla temporal*/
   ADSCreateSQLStatement( "REPTMP", 2 )


   IF ADSExecuteSQLDirect( cSql )

      DBSelectArea("REPTMP")

      REPTMP->( DBGoTop() )


      IF LastRec() > 0  // !REPTMP->( Eof() )

         /*lista resultado en tabla*/
         xbrowse()
         //aArray := FW_DbfToArray()
         //XBROWSER aArray

      ELSE

         /*no se encontro datos que cumpla condicion sql*/
         MsgInfo( "No se ha encontrado REGISTROS" )

      ENDIF

      /*cierra tabla de datos temporal*/
      REPTMP->( DBCloseArea() )




   ELSE

      Alert( "AdsExecuteSQLDirect() failed with error "+ Str( ADSGetLastError() ) )



   ENDIF



   /*se selecciona area de datos anterior*/
   IF !Empty(cAlias)
      DBSelectArea(cAlias)
   ENDIF

   /*da foco al browse*/


RETURN NIL
 

This is my fastest approach.

Please, any suggestions?.


Using FW_DbfToArray() take more time than above code.


Thank you very much. Best regards

Lucas;

Read Marcelo's comment. He is right on the money. You have to start by re-writing xbrowse, or use a grid component from a 3rd party specially made to manage sql result sets, or try with ADO. I think that ADO should work with any sql engine including ADS.

Best regards,


Reinaldo.

Reinaldo,

Yes, the problem is that xBrowse evaluates too many times all events.

In fact, in local mode sometimes is slow, the more using ADS.

Do you know any 3rd grid that works with Fivewin?,

lucas

You can still use the original Listbox class with Sql or .dbf .. here is a sql example with ADO. You will need to write your own skipper() like the one below.

Rick

Code: Select all  Expand view

oRsDEP:= TOleAuto():New( "ADODB.Recordset" )
oRsDEP:CursorType     := 1        // opendkeyset
oRsDEP:CursorLocation := 3        // local cache
oRsDEP:LockType       := 3        // lockoportunistic

cSQL := "SELECT * FROM FREQUENCY order by FREQUENCY"

TRY
   oRsDEP:Open( cSQL,xCONNECT )
CATCH oErr
   MsgInfo( "Error in Opening FREQUENCY table" )
   RETURN(.F.)
END TRY

Do Case
Case nType = 1
    IF EMPTY( zFrequency )
       zFrequency := "BOGUS"
    ENDIF
Case nType = 2
    IF EMPTY( zT_Freq )
       zT_Freq := "BOGUS"
    ENDIF
End Case

*cNAME := UPPER(ALLTRIM(cNAME))

IF oRsDep:eof
ELSE
   IF .not. oRsDEP:eof
      oRsDEP:MoveFirst()
   ENDIF

   Do Case
   Case nType = 1
        oRsDEP:Find( "FREQUENCY LIKE '"+upper(alltrim(zFrequency))+"%'" )
   Case nType = 2
        oRsDEP:Find( "FREQUENCY LIKE '"+upper(alltrim(zT_Freq))+"%'" )
   End Case

   IF oRsDEP:eof
      oRsDEP:MoveFirst()
   ENDIF
ENDIF

lOK2 := .F.

DEFINE DIALOG oDlg RESOURCE "FREQSLCT"   ;
       COLOR "W+/W"                      ;
       TITLE "Frequency Select"          ;

   REDEFINE LISTBOX oLBX FIELDS          ;
     IF(oRsDep:eof,"   ",oRsDep:Fields("FREQUENCY"):Value);
     HEADERS "Frequency"                 ;
     SIZES 90                            ;
     ID 111 of oDlg                      ;
     UPDATE

   REDEFINE BUTTON oBTN1 ID 113 ;
       ACTION ( if(nTYPE = 1, zFREQUENCY := oRsDep:Fields("FREQUENCY"):Value, ), ;
                if(nTYPE = 1, zFREQUENCYEID := oRsDep:Fields("FREQUENCYEID"):Value, ),;
                if(nTYPE = 2, zT_FREQ := oRsDep:Fields("FREQUENCY"):Value, ), ;
                if(nTYPE = 2, zT_FREQEID := oRsDep:Fields("FREQUENCYEID"):Value, ),;
                lOK2 := .T.,;
                oOBJ:Refresh(),  ;
                oLbx:ReFresh(), ;
                oDlg:END() )

   REDEFINE BUTTON oBTN2 ID 112             ;
       ACTION ( lOK2 := .F., oDlg:END() )

   REDEFINE BUTTON oBTN3 ID 114             ;
       ACTION ( _FreqView("A", oRsDep ),     ;     // depview.prg
                if(oRsDep:eof, ,oLBX:bLogicLen := { || oRsDep:RecordCount }),;
                if(oRsDep:eof, ,oLBX:bGoTop    := { || oRsDep:MoveFirst() }),;
                if(oRsDep:eof, ,oLBX:bGoBottom := { || oRsDep:MoveLast() }),;
                if(oRsDep:eof, ,oLBX:bSkip     := { | nSkip | Skipper( oRsDep, nSkip )}),;
                if(oRsDep:eof, ,oLBX:cAlias    := "ARRAY"),;
                  oLBX:ReFresh(),;
                  oLBX:SetFocus(),;
                  SysReFresh() )

    IF .not. oRsDep:eof
       oLbx:bLogicLen := { || oRsDEP:RecordCount }
       oLbx:bGoTop    := { || oRsDEP:MoveFirst() }
       oLbx:bGoBottom := { || oRsDEP:MoveLast() }
       oLbx:bSkip     := { | nSkip | Skipper( oRsDEP, nSkip ) }
       oLbx:cAlias    := "ARRAY"
    ENDIF

ACTIVATE DIALOG oDlg ;
         ON INIT ( if( xSUPER = 'Y', ,oBtn3:Hide() ) )

oRsDEP:CLose()

IF lOK2 = .F.
   DO CASE
   CASE nTYPE = 1
      zFREQUENCY    := SPACE(10)
      zFREQUENCYEID := "BOGUS"
   CASE nTYPE = 2
      zT_FREQ       := SPACE(10)
      zT_FREQEID    := "BOGUS"
    ENDCASE
   oOBJ:ReFresh()
ENDIF

SysReFresh()

RETURN( .T. )

//-------------------------------
STATIC FUNCTION SKIPPER( oRsx, nSkip )

LOCAL nRec := oRsx:AbsolutePosition

oRsx:Move( nSkip )

IF oRsx:EOF; oRsx:MoveLast(); ENDIF
IF oRsx:BOF; oRsx:MoveFirst(); ENDIF

RETURN( oRsx:AbsolutePosition - nRec )

 

Hi,

Can you use your ADS in xBrowse as an RDD more? Of course your can do it, but I do not think is the best way. I think the best is to create query, load and manage data in internal tables, and finally to work in some browse, no matter wich of them. Then modify all records processed. It is a system change, but ultimately offset by the performance.

This is the philosophy SQL, and it's true that you can work also as a RDD, but I think it is the best solution.

You too can handle data with typical command of xBase (skip, goTop, ...) join with SQL commands and this does not alter the way we work, but maybe you need to change the way to do with the browser, no matter which of them.

Just my humble opinion