With QA Xlookup was instantaneous - enter the PIN and the complete F Name, M, L Name, Add1, Add2, City, ST, and Zip was on the screen.

Sesame takes forever. I've tried to split the look up data into smaller files, made them read only, used the original DTF file. Nothing seems to speed this process up. Seach and update is out of the question.

Does anyone have another way of speeding this up? ???

I just tested the internal lookup with zipcode application that comes with samples and found lookups to be instant. Mind you, the zipCode is a 43,042 records, so it is very big.

What did I do?

made another form with

zipCode
City
State

by placeing Zipcode value, I made it xlookup value for City and State.  xlookups were completed just in an instant.  

Yes, you can speed up the XLookup - without making it internal. Using an external XLookup, you can put an XLookup in the GLOBAL CODE section. It will run when the form is opened. It can even be a "bad" Xlookup, using an non-existent LE name in the key field. Just make sure it uses the same .db file as the "real" XLookup that will run later. Then, put the "real" XLookup in the event where it is really supposed to go.

The XLookup in GLOBAL CODE will run first, so the form will take a few moments to open, but subsequent XLookups to the same .db file will be much much faster.

In general, the first XLookup to any .db file will be slow. Subsequent XLookups will be as fast as internal XLookups. So this technique works by moving the first XLookup "out of the way".

This applies to any of the "X" commands.

As an example, try this in Customers.db:

------------------------------------
in GLOBAL CODE:

var str as string

str = @XLookup("c:\Sesame\Data\Samples\ZipCode.db", "Hiram", "xxxxxCity", "Zip Code")
writeln(str)

------------------------------------
in Company ON EXIT

var str as string

str = @XLookup("c:\Sesame\Data\Samples\ZipCode.db", "Hiram", "City", "Zip Code")
writeln(str)

------------------------------------

The XLookup in in GLOBAL CODE will run just before the form opens, effectively "internalizing" the ZipCode.db. Then when you exit the Company LE, the second XLookup will run nearly instanteously.

Quote:


The speed depends on a lot of factors. In a XLookup the speed is dependent on the field types, the total size of the application, and the overhead to data ratio. If you have two Sesame applications that are about the same total size, but one has fewer fields or records and more data per field or record - it will go faster.

Comparing Sesame to Q&A for speed of XLookup is dependent on the characteristics of the applications involved. On some, Sesame will go faster, on others Q&A will go faster - based on the arrangement, type, and size of the data.

If you were to do head to head timing tests, you will need a very wide variety of applications and then average the results.

There are several reasons we do not use indexes, corruption is one of them. The primary reason is to keep things as simple and homogeneous as possible. That way, if we discover that we need to optimize any particular operation, there isn't a specialized optimization technique already in place that might be in the way or too inflexible. Its better to keep things very simple and apply complexity where we need it - as the need is proven.

Consider merging the related databases in one application.  This is available in Sesame thorugh Application Utility Menu Please let us know if this makes significant difference.

When your xlookup is internal (databases in the same application), it is as fast as in Q&A as per my experience.

Wenn i merge the database it's take's a lote of time to open the database, i only use a xlookup to a large database wenn i add data to my database. The large database will furder never use. It could be nice if there is a possible to index the large database, by example like dbase. wenn there the index is corrupted, you remove the index file and dbase makes a new index file.

Alex