There is already support for OpenEdge database to host a Rollbase instance, trying to 'migrate' the SQL to 4GL answered the question on why do the tables gets created from SQL (hence invisible to 4GL)... there are a bunch of table columns that are restricted keywords in 4GL engine :(
Is there any plan to change that in upcoming releases maybe?
Thanks,
Marian
There are no plans to change the column names. The Rollbase tables are "internal" to Rollbase and are not intended to be accessed by ABL (or by other SQL programs for that matter). Even for SQL access the prescribed method is to use the DataDirect Cloud driver and not direct JDBC.
Accessing Rollbase data and metadata should e done through the APIs. The tables for Rollbase internals do share a database with OpenEdge PUB schema, but that is only to enable access to the data in previously constructed ABL applications to be accessible from Rollbase.
If you don't mind sharing, what is the problem you are trying to solve?=
never mind, looks like keyword forget list works like a charm... not really an answer but helps me move further :)
There are no plans to change the column names. The Rollbase tables are "internal" to Rollbase and are not intended to be accessed by ABL (or by other SQL programs for that matter). Even for SQL access the prescribed method is to use the DataDirect Cloud driver and not direct JDBC.
Accessing Rollbase data and metadata should e done through the APIs. The tables for Rollbase internals do share a database with OpenEdge PUB schema, but that is only to enable access to the data in previously constructed ABL applications to be accessible from Rollbase.
If you don't mind sharing, what is the problem you are trying to solve?=
Thanks for explanations Bill,
although I do agree the access should be done through business logic/services layer I don't always do what I preach :)
Say one have already a progress app and would consider adding some web components for it, thought would be nice to just have the rollbase part run in 4gl (might be a separate database though)...
In fact there is no problem to be solved, more like a hunch, while waiting for evaluation license for on-premise install was trying to get around 'too many databases: 2' limitation as would have loved to try connecting a progress database with this little driver I'm using (mainly for reporting but thought about extending it a bit): ganimede.ro/.../overview
What I love about raw-data integration is we get to look at each other database structures and sometimes just get ashamed and make it better once it gets openly exposed like that ;) stilldrinking.org/programming-sucks