From a remote location at one of our sites where the internet connection to the remote server at HQ is a very slow connection, I'm getting extremely slow performance by having Btrieve directly access the mapped drive where the database files are located. However, when I run the same application over terminal services at this remote site it runs dramatically faster.

This seems very counter intuitive to me. Why would adding an extra layer with graphics speed things up? Why does my Btrieve app run so much faster through terminal services rather than directly on a remote machine?

I want to make sure that I understand.  Your remote site (RS) is accessing the server at headquarters (HQ).  If the RS user runs the application directly, it runs slow.  If the RS user runs a Terminal Services (TS) session to a term server box at the RS (which THEN runs across the network to HQ), it runs faster?

Or, is the RS user accessing a TS box at HQ, which is then accessing the database at HQ?

If the latter, then the answer is simple -- database traffic is round trip traffic, and the farther away you are, the slower it will be.  Screenshots are one-way traffic, so network latency has less of an impact.  If the former, however, then things are all messed up, as you have commented.  Perhaps there is a secondary network problem on the "slow" machine?

It is the latter case, not the former case. Is Terminal Services the fastest means of execution for a Btrieve application across a slow network?

Typically, yes.  Again, the problem is related to the round-trip time for the database requests, which must travel the length of the network and back for EACH call.  On a local LAN, with typical database response time under 0.1ms per request, you can read 1000 records (1000 round trips) in 100ms (0.1 second.).  Now, bring in a VPN configuration, with multiple devices in-line, increasing the round trip time (RTT) to 20ms.  (You can check RTT with a simple PING.)  That same 1000 requests now takes 20000ms, or 20 seconds, to complete.

App developers can address this by using Extended Operations to read multiple records in a single request (thus eliminating round trips), but this requires work.  More simply, users use TS or Citrix instead to keep the data on the local LAN and to keep the RTT short. 

The Extended Operations do not address seeking on key fields do they?

I have another problem, from Terminal Services I can't access the local scanner (this is a scanner program) and the options for network scanners or print servers results in all the shared scanners being visible rather than just the one on the machine you are launching TS from, and the only trial I was actually able to get working was extremely slow.

So my question is, how feasible would it be a to write a Windows Service to serve as the database client, and then transmit the data all at once to my program?
 

If you are reading single records, then I agree that Extended Ops won't buy you much.  However, reading 10 single records shouldn't be much of a headache, either.  The biggest issues come from cases where you have to read hundreds of records, or even scan records in a file looking for related data.  For these queries, extended ops can help a LOT.  IN addition, they can filter on keyed fields *AND* on non-keyed fields!  Even better, you can request only portions of the records to be sent back, a real boon for drop-boxes and the like where you really only need a primary key and a display value to be retrieved.

Many applications have been written with an "application server" approach.  In fact, this is how web-based applications work.  I've seen this scaled all the way up to 1200+ users, and it usually works very well, especially if you've got a good application design.  The difficulty lies in that you need to build a custom communications layer for a custom application.  (Many avoid this by using web services (as already mentioned) or using some other built-in comm mechanism in their development environment.  Some COBOL systems have very nice app-server-based solutions to consider.)  So, it's not far-fetched -- just entails lots of work.  IN any evcent, an app redesign is likely going to be the result.  Using a web front end provides some advantages (like the elimination of custom comm code and the ability to use any browser), but this also has a learning curve for the "traditional" developer.

I am reading multiple records which I definitely know I can get with one Extended Op, my concern is about looking up key fields in the secondary tables--I was doing a LOT of inner joins in my equivalent SQL code. Can you do a complex inner join with one Extended Op?

I'm using VB.NET. What is a web front end in VB.NET? I was looking at how .NET enormously simplifies TCP/IP port listeners over the old much more cumbersome WinSock library, but I would have to put a lot of research into how to avoid collisions with connection requests and assign ports for a service layer used by many clients. It sounds like this all comes for free with a web based TCP/IP library. Do you know the name of the VB.NET Import?

I'm getting occasional complaints of memory corruption from my most heavily used app, which I suspect comes from an error in Marshalling. Do you know of a good memory leak detector? Whatever happened to good old Bounds Checker (and WinIce)?

Extended Ops don't do an "inner join" per se, but they DO allow for filters with multiple terms, connected by simple AND and OR elements that evaluate strictly from left to right.  So, Some of your filters should work just fine here!  Since you select the starting key when you read the first record, the data will come back in any order, too.

I don't know how to use Extended Ops in VB.NET, as VB doesn't give you good control over the individual bytes of the calling and returning structure without jumping through a LOT of hoops.  I'd bow out to the other experts here to answer the other questions...