Network Issue

[Jeff Barnes]

Hi All,

I have run into an issue with my app when networked...

If only one system is accessing the files, everything is ok.

When a second system access the files things slow down to a crawl.
It seems Setting Filters is taking forever.

To open my dbf files I am doing:

Code: Select all  Expand view  RUN

USE &cFile SHARED NEW   (where cFile could be something like:   \\myserver\myfolder\mydbf.dbf  )

Then elsewhere in the program I may need to set a filter (when searching for a patient for example).

Code: Select all  Expand view  RUN

SET FILTER TO UPPER(mydbf->Last) = UPPER( ALLTRIM( cSearch1 ) )  .AND. UPPER(mydbf->First) = UPPER( ALLTRIM( cSearch2 ) )

I can't figure out why it works with one user but not with more
Any ideas???

[Randal]

What versions of windows are running on both computers?

[Jeff Barnes]

Windows 7 and Windows 8

I am able to reproduce the problem on two windows 7 pro systems as well.

[cnavarro]

What kind of indexes you use Ntx, CDx ... ?
When you do a simple search is too slow?

[Jeff Barnes]

Using NDX index.
Index's don't seem slow ... only when trying to use filters.

[Jeff Barnes]

I found an old post when someone suggests using an index instead of a filter ... I will give this a try this weekend and see if it helps.

Old Post:

Re: CDX TOO SLOW
New postby stefano » Sat May 11, 2013 2:54 pm

did you try

index on DESTATOF to "TEMP" FOR (DESTATOF = "ARRIVATA" .OR. DESTATOF = "IN LAVORAZIONE" ) MEMORY

I had the same problem with xbrowse (30 pc in the network and for now 15000 records, use dbf and ntx) and it's ok. In fact I can set up filters and indexes in a free way and prg responds quickly.

Stefano

[TimStone]

Jeff,

Most of my clients run in a network situation. Here are some of the things that may help:

1) If you have several users, you need client server ( ADS ) for very fast performance
2) Use CDX. Its optimized.
3) Instead of filters, use scopes.
4) If you are looking for a single record, use indexed files. Build your index on upper case, ie: UPPER( lastname ) + UPPER( firstname ) then do your search the same way.

I have no speed issues, and in some cases, there may be up to 20 workstations accessing the files.

Tim

[Jeff Barnes]

Forgot to mention, I'm using ADSLocal for dbf encryption.
I don't know if that will make any difference.

Never used CDX ... What is involved in switching and is it possible with using the ADSLocal ?
My default RDD is ADS.

[Roger Seiler]

This probably won't help much, but long ago, for reasons I've forgotten, I was taught when opening a file to always use (cFile) instead of the &cFile macro and to always include the ALIAS clause, such as:

USE (cFile) ALIAS MyDbf SHARED NEW

At the time that I learned this, it solved some performance problem that I've long since forgotten. However, having an ALIAS declared for each open table is handy for switching focus between them, via the SELECT command.

- R

[Roger Seiler]

Like Tim, I use CDX indexes (a technology that I think originated with Foxpro). You activate it via the REQUEST command at the top of your app's main PRG, as REQUEST DBFCDX. To use Foxpro memos, you can also REQUEST DBFFPT (though I think this may now be unnecessary, as it may automatically occur with REQUEST DBFCDX. Again, some of this stuff was learned so long ago that I'm a little hazy on it.) Then near the top of your Main() function/procedure, you say RDDSETDEFAULT("DBFCDX"). As I recall, NDX indexes are dBase indexes, and CDX uses a Foxpro technology ("Rushmore"?) that's much more efficient and faster.

If you use RDDSETDEFAULT() then you don't have to identify the indexing method you're using when opening the table. Otherwise, you have to open as follows: USE (cFile) ALIAS MyDbf VIA "DBFCDX" SHARED NEW.

Switching over to FPT memos, which go with CDX indexes as I recall, requires putting each table through a simple automated conversion process. If you what to see how I did it, going from Flexfile DBV memos to FPT Foxpro memos, just download two files from my website:

http://www.leadersoft.com/files/DVF2FPT.LNK
http://www.leadersoft.com/files/DBF2FPT.PRG

This PRG can be easily modified to transfer from DBT to FPT instead of DBV to FPT, if that is what you need. It automatically converts all memo files within a folder.

As for the indexes, just rebuild them after stating one way or the other (above) that you are working with CDX. The syntax is a little different than for NDX, but I think this syntax is all available online on Clipper support sites. If you can't find it, let me know and I'll scratch it up for you.

Hope this helps.

- R

[Jeff Barnes]

Hi All,

I'm going to add some more info here for clarity....

I am actually using NTX not NDX as I mentioned (fingers were faster than the brain).

I don't think the index is my issue. If I scroll through my main patient list there is no slow down at all. Only slows when I try to use the filters.
Also, there is no slow down when only one user is connected. My test database has approx 500 records. I can only imagine how slow it would be with thousands.

In the screen shot below there is a listbox with the patients. Above that there are 4 gets. The 4 gets allow the user to do an incremental search.
As the user types, the list filters to show only the matching records. With one user, the characters in the get show up as I type. With more than one user, the characters have a delay from the time you press the letter to the time you actually see it appear in the get (and then more delay until the list box shows the filtered list).

I tried using the following index but I get a Create error which is tied to the FOR clause. Can NTX indexs not handle the FOR clause?

Code: Select all  Expand view  RUN

INDEX ON UPPER(Patients->Last) TO "Temp" FOR Patients->Last = Alltrim(cLast)  MEMORY

This is the actual filter I am using:

Code: Select all  Expand view  RUN

SET FILTER TO Upper(Patients->Last) = Upper(Alltrim(cLast))  .and. Upper(Patients->First) = Upper(Alltrim(cFirst)) .and. Upper(Patients->ID) = Upper(Alltrim(cID)) .and. Upper(Patients->MRN) = Upper(Alltrim(cMRN))

I feel that if I can get the Set Index...FOR working my problem would be solved.

Any and all input is truly appreciated

Unfiltered:


Filtered:

[TimStone]

Quick response. You have all the trims there...that all requires processing. I use browse for lists. They are indexed. As I type ( no get needed) the highlight repositions on the list. I display the list in the lower part of the dialog and data on top. ON CHANGE refreshes the gets. It's virtually instantaneous.

CDX is optimized for filters if they need to be used.


Sent from my iPad using Tapatalk HD

[Jeff Barnes]

Hi Tim,

Can you send me a sample of how you do this?

[TimStone]

Jeff,

Sorry for the delay. First, I use tData so all of my data is in data objects. So, my samples will look a bit different, but these objects make the work so much easier.

First, lets address CDX. The code is actually quite simple. In the section below, cPath is where the actual files are located. CDX uses FPT files which are much better.

Code: Select all  Expand view  RUN

            REQUEST DBFCDX
            rddRegister( "DBFCDX", 1 )
            rddsetdefault( "DBFCDX" )
            SET DELETED ON
            SET DEFAULT TO ( cPath )
 

When I open a file, it is this simple:

Code: Select all  Expand view  RUN

    // Open the client database and set the index
    oCli := tdata():new(, "eclmst" )
    oCli:use()
    oCli:setorder( "eclcom" )
    oCli:gotop()
 

Using xbrowse, I can do a search:

Code: Select all  Expand view  RUN

    // Define the browse contol
    REDEFINE XBROWSE oLBxcl ID 860 OF oDcl ON CHANGE ( oClir:load(), oDcl:update() ) UPDATE

    // Attach the database
    oLbxcl:setoDBF( oCli )

    // Add the columns
        add to oLbxcl header "Account" data oCli:acrnum ALIGN CENTER ORDER "eclnum" SIZE 120
        add to oLbxcl Header "Client" data oCli:clicom ALIGN LEFT ORDER "eclcom" SIZE 300
        add to oLbxcl header "City" data oCli:clicty ALIGN LEFT SIZE 250
        add to oLbxcl Header "Phone" data oCli:clipho ALIGN LEFT ORDER "eclpho" SIZE 200
        add to oLbxcl Header "Cellular" data oCli:clicel ALIGN LEFT SIZE 200
        add to oLbxcl Header "Email" data oCli:clieml ALIGN LEFT SIZE 300
        add to oLbxcl Header "Last Visit" data oCli:clidls ALIGN RIGHT SIZE 150
        add to oLbxcl Header "Y-T-D" data oCli:acrytd ALIGN RIGHT  SIZE 150

    // Use for incremental search on opened database
    oLbxcl:bSeek := { |c| oCli:Seek( Upper( c )) }

 

Of course there is more code to go with this relative to display, etc. However, in the browse, you can simply start typing ( no get field necessary ) and it will re-position the highlight bar to the closest record.

Tim

[elvira]

Timm,

What is tdata class?.

Thanks