The following are answers to questions posted by MIDAS/DataSnap Guru and all around great guy Dan Miser.

Does it (ASTA) allow you to do RPC?

That is actually what Josh Dahlby asked me a while back on the midas forum. ASTA doesn't use a "standard" RPC like DCOM or Corba. Here is a definition of RPC:

"Abbreviation of remote procedure call, a type of protocol that allows a program on one computer to execute a program on a server computer. Using RPC, a system developer need not develop specific procedures for the server. The client program sends a message to the server with appropriate arguments and the server returns a message containing the results of the program executed."

ASTA supports this is a number of ways.

1. ASTA has a complete and easy to use messaging layer that was designed for Database application developers to use with no knowledge of sockets or DCOM. At the lowest level, you can just SendCodedMessage which sends a Msgid:Integer and a Msg:String. On the server, you code a Case Statement and do what ever needs to be done.

2. There is also a SendCodedStream and SendCodedParamList. Once we has the SendCodedParamList we had all we needed as TAstaParamLists can handle any kind of data including all the normal vcl types as well as binaries and even datasets and other ParamLists. ASTA ParamList messaging is supported Cross Platform including Palm, Wince, Java and Linux Pda's

3. TAstaBusinessObjectsManager: Here you can define server side methods (remote procedures if you will) along with their Params. On the client the TAstaclientDataSet sees a list of available server methods at design time and pulls down the one to use. When that happens the Params are streamed down from the server along with the type (datatype, input type). At runtime you populate the Params and when you set active to true, the Remote Procedure is executed and a dataset and any output params are returned to the client. Optionally the ServerMethod can be set to execute asynchronously so the client does not have to wait. The ServerMehtod doesn't have to even have a DataSet attached to it. In fact in ASTA 3.1 any servermethod will be able to be puplished as a SOAP Servide through an ISAPI dll or ASTA supplied HTTP Server.

There are additional options like to launch the action and return control immediately to the client (async) for long running server processes. And also the ability to send back the Field Properties of the attached DataSet. The DataSet can be attached directly to a server method OR a TAstaProvider can be used and that DataSet is used by the BizObject Method.

Now get this: any Params defined by the TAstaProvider will come back to the client. Not only BDE Params (see how non bde midas support is) but any third party param even if it is not a TParam.

All of the above supported in all 4 ASTA threading Models.

How does it handle threading on the server?

Midas 3 introduced Pooled Threading which ASTA has had out of the gate. ASTA servers can be run in one of 4 threading models:

• Single
• PersistentSession (the old midas one datamodule for each client)
• Pooled (the most scalable )
• SmartThreading - mixes Pooled and Persistent threading. The best of all possible worlds.

ASTA supports threading internally so you never have to create a thread or do anything with threads. This support extends to the 30 or so current Delphi 3rd party Database components support by ASTA. And ASTA 3 Servers can run as services or normal EXE's out of the box and also support Remote Control, Remote admin and SkyWire (non-vcl clients like Palm and WinCE) clients.

And this is not COM threading but winapi threading which we feel is much lighter and scalable.

How functional is the client side dataset support? Does it do filters, ranges, locates, indexes, sorting, storing to disk, etc?

Yes, ASTA 3 has filters, Indexes, Aggregates, Locates, Sorting, saving to file using ASTA binary format or XML in ADO or Midas format. Also the save to file can be encrypted or compressed.

We also support cloning where datasets can be edited and affect other datasets. (inserts, edit, deletes are cascaded. midas has this I believe)

How complete is its master-detail support? Can you post the master-detail updates in a single transactions? Can you fetch details on demand? (With Delphi 4, the details can come in the single datapacket with the master, one of the cooler enhancements in D4.)

You can post any number of AstaDataSets in one Transaction using the SendDatasetTransaction call which takes an Array of TDataSet. We support master detail either through the complete fetching of the detail and using filters or the firing of a paramterized query on each master change of the detail (no code required).

We have not done the ftDataSet datatype that midas has to support the extended SQL syntax introduced by microsoft. We do have a little used feature we call Expressway SQL where you can send multiple SQL statements in one SQLTStrings and a dataset is returned with all the datasets in a blob field. I did this one day when someone wanted to fetch a bunch of queries in one server round trip. There are also Expressway SQL options for Asta Providers and Server methods to bring back any number of them in one trip to the server.

Does it support constraints defined on the server that are enforced on the client?

Yes. ASTA 3 has extended constraint support similar to DataSnap.

Does it propogate field properties to the client?

Yes, using our server side components.

Traditional multi tier midas programing requires a server side provider for each client. We support this but also pioneered Client side sql.

Run any of our servers canned out of the box (try this with midas) and they will thread and you can develop and deploy a thin client (no dll's like midas) app using sql. Converting c/s apps can be very quick using this technique. We support pure ntier development but don't require it. ASTA learning curve (no com) can be much less than midas.

How does it apply updates on the server? Does it generate SQL based on the updates? Can you customize how that SQL will be generated?

We support AfterPost and Cached updates using client side sql and the SQL is configurable with lots of properties and events. (eg post booleans as integers for ms sql server. just a property to set once on the TAstaclientSocket application wide).

We also support server side sql generation where an oldvalue and current value dataset is shipped to the server and passed to TAstaProviders which have events that fire before insert, before update etc AND you can modify the datasets or handle the sql you want and have ASTA not fire sql.

We also support refetching autoinc fields and default fields for all our 30+ ASTA servers. There is a new TAstaUpdateSQL component that allows for further customization of SQL.

If you have read this far, ask Dan if Midas has this:

AstaProviders and a broadcast ability to send out any change to any table/row to any interested clients. With NO Code. Instant Auction app with no code. Read about it from this link: Conflict Management.

How does it handle reconciliation errors?

ASTA has a conflict management tutorial to show how it can be handled.

How much control does it give you over the data on the server?

You can do whatever needs to be done and even map fields from components like IBExpress that bring back TIBString Fields to normal VCL fields.

ASTA is a mature product now with many more features that I've discussed there. Midas is fabulous technology but ASTA 3 has a huge number of features that Midas probably will never have:

• Built in Encryption Options including DES, AES and RSA Public Key exchange
• Built in authentication for http stateless clients using cookies
• Instant Messaging API
• Unlimited licensing available
• Palm, WinCE and Java Client Support
• Auto Updates
• NO DLL's required (the midas client dll's are written in c++)
• No DCOM
• No winsock2 requirement

You'll find our support the best that can be had and we listen to our users and implement new features almost upon demand. that's how ProviderBroadcasts came about. After ASTA 2.0 was released a couple of guys wanted to do it so we coded it. There has been dicussions whether compression is always faster or not, so we no provide selective compression on ANY individual query. write some sql. want it compressed at the server? set a property execute it. Don't want the next one compressed? turn it off.

Watch for the AstaIO 2.0 release in the fall of 2002 with a Midas compatibility layer.