The only thing we can try and give you at that point is a workaround, and in my case, also an explanation of why I wouldn't conect to the database directly in the first place.
I think these thoughts and advice should be posted as a warning to other users like me, in a visible place. I feel fooled if I got caught from advertising.
If you can factor out the database calls into a separate library stack, you can reuse these from cgi-scripts. Then it's a matter of rewriting the calls to this library on the client side, into a HTTP get/post driven approach.
I agree, now I see that interacting with remote databases deserves a different approach.
But if dealing with remote databases requires writing the cgi part first (server side), then this tool does not seem to be a good front end creator. You have to work twice; first the server side, next the client side. Phew!
Personally I do not have time to re-invent the wheel at this moment. Most webservers (especially *nix flavour) offers cgi tools.
I really appreciate your time and thoughts Jan. Do not get me wrong.
I do think that RR advertising database capabilities creates a false expectation. I got involved with RR for this database project. In order to be accurate it should state something like: "superb cgi development tool" or "if your project uses databases then think in the server side first".
And yes, a project like the one I'm facing requires a server side solution. It's time to move on... after wasting lots of hours learning/wrestling with RR.
If frustrating experiences are not allowed in the forum delete the whole thread.