Page 1 of 3
Network Issue
Posted: Fri Jan 10, 2014 9:09 pm
by 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
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
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???
Re: Network Issue
Posted: Fri Jan 10, 2014 9:12 pm
by Randal
What versions of windows are running on both computers?
Re: Network Issue
Posted: Fri Jan 10, 2014 9:17 pm
by Jeff Barnes
Windows 7 and Windows 8
I am able to reproduce the problem on two windows 7 pro systems as well.
Re: Network Issue
Posted: Fri Jan 10, 2014 9:20 pm
by cnavarro
What kind of indexes you use Ntx, CDx ... ?
When you do a simple search is too slow?
Re: Network Issue
Posted: Fri Jan 10, 2014 9:22 pm
by Jeff Barnes
Using NDX index.
Index's don't seem slow ... only when trying to use filters.
Re: Network Issue
Posted: Fri Jan 10, 2014 9:23 pm
by 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
Re: Network Issue
Posted: Fri Jan 10, 2014 9:44 pm
by 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
Re: Network Issue
Posted: Sat Jan 11, 2014 1:09 am
by 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.
Re: Network Issue
Posted: Sat Jan 11, 2014 3:26 am
by 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
Re: Network Issue
Posted: Sat Jan 11, 2014 4:08 am
by 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
Re: Network Issue
Posted: Sat Jan 11, 2014 12:49 pm
by 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
INDEX ON UPPER(Patients->Last) TO "Temp" FOR Patients->Last = Alltrim(cLast) MEMORY
This is the actual filter I am using:
Code: Select all
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:
Re: Network Issue
Posted: Sat Jan 11, 2014 6:06 pm
by 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
Re: Network Issue
Posted: Sat Jan 11, 2014 6:19 pm
by Jeff Barnes
Hi Tim,
Can you send me a sample of how you do this?
Re: Network Issue
Posted: Mon Jan 13, 2014 4:21 pm
by 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
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
// 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
// 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
Re: Network Issue
Posted: Mon Jan 13, 2014 4:42 pm
by elvira
Timm,
What is tdata class?.
Thanks