Hello Bruce and all others!
For several reasons I am using TPS and am quite happy with that. Nonetheless I try to make my app more robust, so I thought of using the IP-Driver. But in my opinion its too "monstrous" and beside that I was not able to get it running out of the box. I know others do, but that is not help for me.
My idea is to have Win32-Clients on the network, sending requests to SOAP-Server, receiving back datasets to display.
Those Win32-Clients may be distributed onto the Client-machine, running locally there, or may be called from a desktop-link, IOW they are actually still sitting somewhere on a server. But thats a problem of the admins and how they want to maintain the install.
I have played with Example 42 SOAP-Server, which nearly covers what I think of. But other than the Example 42, I have to display quite some listboxes.
Does anyone have experiences about the limitating numbers, about how many records can be transferred and displayed?
My idea is to display the received dataset with InMemory-tables. I am in the comfortable situatiuon that the large tables, 1000 to 2000 records, are for reading only. The number of records in some listboxes that get written, is relative small, just 20 or 30 records. Think of thousands of CUSTOMERS, with thousands of INVOICES, but only one invoice will actually be listed in a listbox and these items are set for writing back intoi the TPS on the server.
Anyway, sending 1000 CUSTOMER records from the server to be listed in the clients listbox (page-/file-loaded?) for picking the right one, is that a reasonable scenario with a Client/Server combo based on SOAP and XML?
What would be the appropriate driver on the client-side? InMemory? Queue?
What do I have to expect when I send back a single record for writing back into the TPS, when in a multi-user-environment?
Is it worthwile to continue on such a scenario at all?
Thanks for your patience,
Wolfgang