Creating tables/Fields in DB programatically from ABL

Not that I am aware of.

Easiest path is probably to create an incremental df file and then:

RUN prodict/load_df.p ( cdfdir + cdf_name ).

Depending on your configuration (AppServers, WebSpeed agents, others) you may have a hard time getting a schema lock.

To be able to execute the above your 'client' needs to be able to compile code or be started with the -rx option. If not we disconnect the connected databases and spawn a copy of the current session with -rx added to the command line.

battling with the editor to get code marked as code

I suspect the easiest is to programmatically create the .df file and then run the dictionary programs to load it.

The API does support load of .df files.

The API is available from OE11 on - right? Is there documentation available? I mean outside the code, which accidentally has one or two comments but not much more.

And speaking of the data admin API's.

I recently logged Bug OE00236179 which relates to the DataAdmin tool, but is actually reproducible when using the Data Admin API. When setting a list of security administrators for one DB, then selecting a different working DB (DICT-DB) and then trying to change the security administrators for the second DB you end up setting them for the first one. That seems to be a bug in the data admin API.

Is it tested, that the load DF functionality in the data admin API's work when swtiching the working DB, aka DICT-DB?

The API was introduced in version 11 and is documented in the Programming Interfaces document. http://documentation.progress.com/output/OpenEdge112/pdfs/dvpin/dvpin.pdf

The interfaces are mostly well documented.

The API was introduced in version 11 and is ducumented in the Programming Interfaces document.

That's good to know!

The interfaces are mostly well documented.

Must have looked at the wrong source then.

Yes. For now, this is the best way to create table definitions from 4GL code. Use of this (long-standing) API is supported.

The new API that was introduced with v11 is used by the database administration console (aka DBAC) part of OpenEdge Explorer and OpenEdge Management under the covers.

It doesn't do everything. But it is documented and supported. More functionality will be added to it in future releases.

mikefe wrote:
And speaking of the data admin API's.
I recently logged Bug OE00236179 which relates to the DataAdmin tool, but is actually reproducible when using the Data Admin API. When setting a list of security administrators for one DB, then selecting a different working DB (DICT-DB) and then trying to change the security administrators for the second DB you end up setting them for the first one. That seems to be a bug in the data admin API

The utility and the API is using the same code, so they may very well expose the same bug, but the DataAdminService is supposed to work against the database provided through the constructor, so you should use a new service for a different database. If you actually used two services against different databases, and they both updated the same database then this would be a bug in the API.

The latter is the case and the fix is scheduled for 11.3

I did some tests creating  a .df file and then using the DataAdmin API to apply it to the DB. That worked fine, so we will go that way.

Is there any documentation available on the .df format? Especially the meaning of the "position" and "order" options are somewhat unlear to me.

Thanks to everybody for all the useful tips!

Mike

Another option:

https://code.google.com/p/pct/wiki/PCTLoadSchema

Is it tested, that the load DF functionality in the data admin API's work when swtiching the working DB, aka DICT-DB? 

The load df is not affected by the OE002369179 issue and works as expected with multiple services.

I am out of the office until May 21st 2013. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.

If you need support from appSolutions, please send your mails to support@app-solutions.com.

If you need Roundtable support, please send mails to :

support-europe@roundtable-tsms.com.

Jeg er væk fra kontoret indtil den 21. maj 2013, og checker ikke mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.

Hvis du har behov for support, kontakt venligst support@app-solutions.com, så vender vi tilbage så snart det er muligt.

Administrative henvendelser kan ske til : admin@app-solutions.com.

Med venlig hilsen / Regards

Thomas Hansen

appSolutions a/s

I wrote

The API does support load of .df files.

The main purpose of adding this to the API is to give access to new partitions created as part of the load (see documentation). The API version of Load .df is using the same internal code as the old prodict/load_df.p and provides a few improvements also for non-multi-tenant cases.

1. Uses current ABL error handling mechanism instead of inline message boxes wherever an error is encountered.

routine-level on error undo, throw.
service = new DataAdminService("mydb").
service:LoadSchemaChanges("mychanges.df").

catch e as Error:
     
end catch.

2.  The DataAdminService:GetSchemaChanges can be used to check the .df without applying.  

The load df is not affected by the OE002369179 issue and works as expected with multiple services.

Thanks for testing that!