More detail Documentation


I'm planning to buy this suite in order to move my old Asta N Tier applications.

But I did not find more detailed info about all the methods and properties, with Asta a did a lot of routines like the "broadcast" messages, autentication, zip and cypher chunks of packets. And much more.

Basically my first goal is to buy this RemoteDB suite in order to use it in my iOS and Android so I need to know your answers for the next questions:

1) If I want to check all the request to the RemotDB server and let pass only those from a mobile Device... NOT from a PC how can I do it

2) What about encription and zip data does exist this default routines in your technology or I need to code it?, if so where I have to code this routines?

3) On your demos there's a URL or URI default address when it's exposed at Internet all the methods are exposed too?

4) The refetch on insert triggers are coded in your suite?? So when I record is inserted on any supported database it's returned the selected field?

5) How many concurrent users are supported for your RemoteDB server?

6) Can I have business logic methods coded in your RemoteDB server in order to use it on the clients?? as TAstaClientDataset technology was?

7) What's the default timeout request of your technology? and does this event be triggered on Server and Client sides?


Hello Romero, 

1) You can use Sparkle middleware to intercept and filter any request in any way you want:

3) I didn't understand this question?

4) That should be done manually

5) As many as your server can hold. RemoteDB has a nice mechanism where even though it creates one connection at server-side per client user, the connections don't need to stay open all the time (except when transactions are open), thus the connections are destroyed after idle time, even if the client is still active. When client performs another request, server reconnects to database.

6) No. For business logic methods you should use XData (which can coexiste its RemoteDB nicely):

7) Which timeout are referring too? If it's connection timeout it's of course client side, and default value is 60 seconds.


I'm a TMS Software user since 2014, I was consuming soap service with Delphi XE 6 and so on.

Right now I'm with Delphi 10.3.1 Rio and seems there are a lot of troubles compiling for Android.

My old code based on THTTPRIO stuck on Android.

Can you please help me with the next issue:

I compiled an App for Android and after 3 SOAP request from my App Client the App hangs up and does not respond, the first two request are logged into the HTTP server but the 3 not. Why?????

On iOS and Windows it does not have this issue and it's the same code.

Can you please point me in the right direction?


What server are you contacting with? Is this related to TMS Business (XData or Sparkle)? We do not provide components for SOAP servers, only REST ones.

Maybe it's worth to contact Embarcadero about this issue?

It's very complex your documentation

I can't build a simple REMOTEDB server with compression enable

What did you try? What is the error you get? 

Compression is enabled by default in the RemoteDB server, and from the client using TRemoteDBDatabase component, you can control it using the Compress boolean property.

Who says so??? I did not find any information about this in your documentation.

Yo answer in this same thread the next lines:

"2) Zip is also a middleware (compress): Encryption is done using HTTPS:

So everything is confuse, only employees of TMS understand your own rulez

The compress middleware is a generic middleware that serves any Sparkle server. XData, RemoteDB, Generic, StaticFile, etc.. Whenever you want to add the ability for the server to respond to an accept: gzip or deflate request from the server, add the compress middleware.

Specifically for RemoteDB server, it already responds to deflate, and the RemoteDB client database by default already sends that header to the server. RemoteDB is not a general-purpose HTTP server. It has its own format and it was built to enable communication between the server and a Delphi client for the sole purpose of proxying the database. There is no much need in protocol documentation as it's used internally by RemoteDB. The Compress property simply controls if the client is asking for response to be compressed or not (depending on the network configuration, either option might be faster).

I think we still stuck on many questions, because last year after I opened this post I wrote you the next lines:

"Basically my first goal is to buy this RemoteDB suite in order to use it in my iOS and Android so I need to know your answers for the next questions"

So you knew I was focus on RemoteDB, but complex your answer telling me to use compression with a middleware, this was garbage assuming you knew that RemoteRB is already prepared with deflate compression

Please read again the first message of this thread and try to make me life easier.

Also what happend if somebody use a sniffer in order to catch all the traffic between your RemoteDB solution???

What's the security level you offer with this suite??

Basically I will code a simply Application for iOS and Android that "log" with some mechanism as username, password or imei and then request many data to the RemoteDB server, also the same App will send data in order to RemoteDB server save it to DB in a trasactional manner.

It's so simply, does RemoteDB will simplify my life???

Are you able to code me a RemoteDB Win64 Application with some basic rulez like "login process", request data & send data samples???

This is very important in order to buy this suite, I need to be sure this suite will solve my actual needs.

RemoteDB provides data through HTTP(S) protocol. If you want your data encrypted, use the common approach for HTTP requests which is secure it (HTTPS) using a certificate. You can get free ones these days, here is a blog post about it:

RemoteDB is a "quick" way to turn your database into the cloud and make the connection abstract through HTTP (instead of connecting directly to the database). But that means the SQL is provided by your client, and anyone who has credentials to your server is able to execute arbitrary SQL statements.

If security is a high concern of you, you should create a server with business logic, with limited access to clients, which then you should be using XData which is a standard REST/JSON server.

With RemoteDB you just code your application as you would be coding a client-server application. The approach is the same. Drop the query component, the connection, write your SQL and execute it.

About XData, there is the documentation and several videos in our Youtube channel and post in our blog about its usage, besides some demos which are installed in the package.
for my application RemoteDB was the perfect solution; easy and fast to develop.
But I am curious about XData...
Can you tell me an entry-point in the documentation where it is explained for newbie to REST architecture ?
Can it be used with the new WebCore framework also ?

Hi Marco, yes, it's the recommended server for TMS Web Core.

There are many XData resources:
Tutorial XData + Web Core:


What about the autentication example I requested you before???

I can't buid any RemoteDB server yet.

It's hard you to provide me a simple demo with "username" and "password" autentication ????

RemoteDB already has built-in basic authentication enabled, with a default user name and password. Meaning to access the server you need to pass such credentials in HTTP request headers. 

When you use the remotedb database from a VCL client, it's already built-in.

RemoteDB is not an application server. It's more a "proxy" for SQL statements. Users usually do not "login" to RemoteDB server, it's your application that uses it. 

Alternatively if you really want to, you can use JWT authentication with RemoteDB server as well, as described here:

The different is that, since RemoteDB doesn't have server-side logic, you would simply add the JWT middleware to validate token and check the expiration, and that's pretty much it. 


My main concern is to avoid any hack with some sniffer tool.

If RemoteDB have all the necessary routines for encription and the data travel secure then I really don't need anything else.

I will build Apps with the old Client - Server model, so if TMS business it's very easy to incorporate at my iOS/Android projects then you pass the test.

I will publish the App's at the Google Play Store and AppStore for free download, at the initial screen  will always request "username" and "password" and that data will travel to the RemoteDB Server in order to see if that is a valid user.

Just point me in the right direction with Encription between my RemoteDB Apps and the RemoteDB server and that's all.

Thank you very much

Security always depend on your requirements. 

Using HTTPS (SSL) is the "standard" way to avoid man-in-the-middle attacks. You are going to use the encryption mechanism used by most of people out there. Imho is better than having your own encryption.

RemoteDB architecture itself is not as secure as XData, for example. That's by design. You have a server that executes SQL statements remotely, all SQL statements are at your client-side, and if any user has access to server credentials, it will be able to execute arbitrary statements over it. That's how it is, that's the cost of having something so easy to develop using a "client-server" paradigm.

If such architecture is not an issue for you, then SSL encryption is not your biggest problem.

Thanks for your faster respond

My last question for "now"..... I will test the HTTPS with the links you gave me, however in order to someone download my Apps I need they enter a username and password initially once downloades the App and run for the first time.

The question is:... at the initial screen of the App I will connect to RemoteDB server and validate the username and password entered in my input boxes and that's all??? if it's a valid user I will allow the use of the entire App correct???

That's up to your application. RemoteDB requires authentication for it to execute SQL statements. That's under the hood. How the authentication will look like to your end-user and what he can do with your application is out of RemoteDB scope.

RemoteDB doesn't judge the SQL being executed and doesn't have server-side logic. All it does is to execute SQL statements. All authorization question it does is "is this user sending valid credentials to use RemoteDB? Check. Then he can execute any SQL statement he wants".

I think finally I got it

Thanks Sir