Just thought that the techniques shown below might be of interest to some folk somewhere. It is a copy of a posting in a dBase newsgroup.

Subject: Horses for Courses - may be of interest !!

Good Afternoon Folks
 I am very very reluctant to make this post - When you get to the end
you may understand why !!

 I seem to recall a thread recently about "performance" or maybe it was
"response times", it seemed to me to have degenerated into what a 'brit'
would call a "slanging match" - please be aware, that if this leads to a
similar thread, I will not be joining in .

 Those that know me will be aware that I am a great believer in trying
to select "horses for courses". That is how this started. The results
seemed worthy of me making an effort and telling you about it !!

 If it is of no interest, forgive me for wasting your time.

 Several years ago, (before dB2K) I wrote several serious data
processing applications that used Web Browsers as the user interface.

 Let us call this STEP ONE (and use it as the benchmark for the rest of
the steps)

 The technology used was:-

  Input to Browser ->
  http ->
  IIS (asp file) ->
  dBase 5.7 exe file ->
  back to the waiting ASP file ->
  Redirect to the file just written by dBase ->
  Web browser

 The result (obviously) did not give the "sub-second" responses of local
dBase (or Delphi) .EXE files - but the users loved it !!

 STEP TWO

 Was the new dB2K technology (no ASP !!)

 The result (on the same server, using two side by side clients
simultaneously) was a reduction of response times to between 80% and 90%
of those in step one.

 Would the improvement justify the re-writing of several MBytes of code
? - it didn't seem like it to me.

 STEP THREE

 The Technology was:-

  Input to Browser ->
  http ->
  IIS (asp file) using MSXMLdom to access XML files created from the
dBase tables ->
  Direct response to the browser from the ASP file ->
  Web browser

 The result (on the same server, using two side by side clients
simultaneously) was a to response times tending towards infinity,
completely and totally unacceptable.

 Deep despair - about to throw in the towel.
 I had done so much clever programming - created indexes - fast binary
chopping to get the key for the node that I needed - most disappointing.

 STEP FOUR

 Decided just out of idle curiosity to abandon my "clever code" and do
the job by "serial reads" of the XML data.
 Scared me witless - the average size of the XML files is about 1.5
MBytes !!

 Surprise, surprise, the result was  a reduction of response times to
between 10% and 25% of those in step one.

 Quite unbelievable - MSXMLdom is not fast at finding by key, but
reading the whole file it flies !!

 CONCLUSION

 This technology is worth pursuing - clients are "pressing money into my
hands" to migrate their big systems !!

 HOWEVER

 I am resisting the temptation to do this until I get MDAC upgraded to
the latest so that I can access dBase tables directly from the ASP. That
will be STEP FIVE - it could be better still !!

 BUT

 When clients say "is XML proprietary ?"

  and then "are dBase tables proprietary ?"

  what the devil do I say ???

Hope that it has interested you - is dBase the best way to proceed for
good fast Web based systems - (I have no doubt that it is for "Local"
processing)

Anyone wanting to know more, please ask - if I can tell you, I will.

Best Regards
Pete (Northolt UK)