Network Issue

[James Bott]

Tim,

Two points.

1) Jeff wants to be able to search by more than one field at a time, so incremental searching would have to include a filter also. This would obviously slow down the search--I don't know if it would be significant.

2) Are you referring to your systems using ADS or those without?

James

[TimStone]

James,

I use ADS LOCAL and REMOTE, or straight DBFCDX. Any can be set in the config file.

I consider that file size to be quite small, so the broad search across multiple fields really puzzles me.

Tim

[James Bott]

Tim,

I consider that file size to be quite small, so the broad search across multiple fields really puzzles me.

Me too. I have never had a situation where I thought this was needed. This is why I suggested defining some use case scenarios. Perhaps the user sometimes has only a first name and part of an ID number or? I am having a hard time picturing the user having only a partial ID or MRN number. Normally you either have the entire number or not. And if the user has either the entire ID or MRN, then that is the only info needed to find the desired record (presumably these are unique numbers).

Maybe this needs some rethinking. Jeff, did you just design the app this way, or did user's request the multiple field search? Are the users actually searching on multiple fields? Some examples? Are the ID and MRN's unique?

James

[TimStone]

James,

What I like about the browse situation is that it is so fast in practical use. First they try the search on the customer field ( which is either a company name, or in most cases, last + first ). There could be a field for the last 4 digits of a social security number ( that's pretty common ). Most people know that. You can also have the address field and phone number field ( add email if you want ). All are indexed. Simply click on the header to change the type of search. It is instantaneous.

Now, because its a browse, each of those columns is shown, so they are not unique. If its Smith on Oak Street, I can put in Smi and see the lists of Smiths. There are not many in a population of 400, or 1000, records. Then I look across to the address, spot the one on Oak, and double click on it. Voila ! I'm now looking at the right record. Total search time might be 3-5 seconds with my "filtering" visually. On unique names, in that size database, I might find what I want in 1 or 2 seconds.

I learned many years ago that often someone says "This is what we need" and when we actually discuss it, they see that's not at all what they need. Also, sometimes they think of features in terms of something someone sees in an app, so they think it can be universal.

Tim

[Jeff Barnes]

The MRN and ID fields are indeed unique to each patient (clinics will use just one number but some hospitals require the two id fields).

The MRN/ID fields do not really need to be incremental as you mentioned but I would like to have the name fields allow for this. It was simple enough with the "Filter" to allow this.

In time the database will grow... In an older app (similar to this one but not as functional) I have customers with 70000+ records. Obviously I will need to get this sorted out before it grows. There are other sections of the program that currently use filters so once I have the patient search figured out I can implement the change for the rest of the program.

I am open to all ideas. Sometimes one persons view gets "locked in" and we need others to help remove the blinders

[James Bott]

Tim,

What I like about the browse situation is that it is so fast in practical use.

You're preaching to the choir. I developed my first incremental search using a list way back in the early Clipper days.

James

[HunterEC]

Jeff:

As Tim & Roger has explained you'll reap a lot of benefits from using CDX indexes. Filters ARE ALWAYS slow. Use SCOPES and INDEX.
With an INDEX you can do incremental searches.
Index size on CDX are way smaller than NTXs. Why ? By default they compact / compress repeating key values. For example: if you have an index key based on DTOS(dDateField) and have 1000 records with the date field set to 01/15/2014 (DTOS() will produce 20140115), the NTX system stores 1000 times the same value in the index. On the other hand, CDX store it only once and saves a counter that this is a key that repeats 1000 times. When I converted my app to CDX index, size went down at least 40% !!!!
Besides, each NTX file takes an Operating System file handle. A CDX file stores all your indexes on one physical file consuming ONLY 1 file handle. Also if you named the CDX file the same as the DBF, it automatically opens for you. On NTXs you have to open them manually. All this lowers your bandwidth consumption.

Also trying to connect your users through RDP, is by far faster than using network shares alone, more secure and less prone to data corruption.

I hope this clarifies some of your doubts. If I can be of any help, please drop me a note.