Hi Jon, thanks for the reply.
I guess some of this comes down to what you define as an Ebase developer? One of the big selling points of Ebase used to be the capability of having form writers who were not technical developers. We used to have non IT people writing forms (or parts of forms) and IT technical staff bolting stuff on for consumption. A form writer may not need to know how to connect to the database or have no knowledge of sql as they simply fetch/update a table that has been written/configured for them.
Ebase appears to be departing away from this approach in other areas like client side programming and the palette entities not being widened (eg dialogs,trees,accordions). Not a negative point as the power of the product is moving in other directions.
From a security perspective we need to know/restrict/limit who is connecting to a database and by device. I understand that there is potential for us to widen this approach onto MSS.
There is often the argument that it's only a development database. But where we interact with large 3rd party applications there is the risk that the non production environment holds real (or close to real) data. We use Ebase as an integration mechanism (and excellent it is too).
At this time all bar 1 of our Ebase form writers are IT staff so we can have reserved IP addresses and the device has explicit permissions to connect to the databases. It does limit our capability / increase the complexity to have users doing some form stuff but it is manageable.
Of course we still have the external server approach that may work in some situations eg very small workspace where the designer points at the workspace on the server - something I'll look at tomorrow. I looked at a remote workspace sometime ago but it was way too big to be workable.
Not quite ramblings but getting close
