OHDSI Home | Forums | Wiki | Github

Updating Atlas cohort defenitions not showing up

Upgrading from a very old version 2.50 to the newest 2.11

I have copied the source table exactly as it was in the old version and the connections work. However, none of the old concept sets are now showing up in Atlas.

I was hoping to be able to use all the ones that had been created for the years in which the old version was in production.

Is there any way to keep those old concept sets and cohorts from an old to new version?
Am I just missing something?

Any and all help is appreciated.


There should be no reason that the assets like cohort definitions and concept sets should be lost going from 2.5 to 2.11.

Could you query your webapi cohort_definition and concept_set tables? They should have data in them. The biggest change from 2.5 to 2.11 was a change in ‘autonumber’ fields, but without further information, I can’t tell. Can you provide details about what is in your cohort_definition and concept_set table and we’ll take it from there.

Hi Chris,

So I have a new webapi database that the updated instance is looking at. Looking at those tables they are empty in the new one and have all the data stored in the old one.

I had thought the cohort and concept data was stored in the ohdsi_results database but I guess that is incorrect. Thank you for the clarification.

This leads to another question is if it would be possible to use an older version of the webapi database with a new version of the webapi?

The old database was created alongside webapi version 2.5 and the new version of the webapi is 2.10

When I tried to point the new version of the webapi at the old database it spit out a number of SQL errors with the same error message:
ERROR: there is no unique constraint matching given keys for referenced table “source”

This along with the fact that there are a number of tables that don’t appear in the old version led me to believe that the two are not compatible.

If this is not the case please let me know.

Is there any good way to migrate the old data into the newly updated database?
ie. would it be as simple as taking all the data from the old concept_set and cohort_definition tables and any associated tables and putting them into the new database?

Thanks for your help!


Pointing the new version of the WebAPI application at the existing (old) webAPI database should have auto-migrated all tables (including creation and drop) to the newer schema in v2.10. If there was manual changes made to the WebAPI database, then the migration scripts will not know how to handle that and the migration scripts will fail.

The error message you provided isn’t clear enough without context (such as which migration script led to the error, or if it was some other error on startup).

If you want to try to migrate from one WebAPI instance to another, you could look into using ROhdsiWebAPI to query the old WebAPI instance for the existing assets and then post them to the new webAPI instance for loading.

You could also look at a more ‘raw’ database migration where you export the data from the old tables and then bulk-insert them into the new tables, but this is a very technically complicated maneuver where if you don’t import the data in the right order and use the right database sequences you could make a mistake that will cause the application not to work.

It’s also not clear which version of DBMS you are running on so I don’t know if there’s any database-specific information I could give you.

Worst case scenario is you keep the old WebAPI running in 2.5, and have the new application running on 2.10, and you can export-import from one application to the other. A way you could do this is if you create a cohort characterization, add a bunch of cohort definitions to it, and then export the cohort characterization, you can import the characterization design into the new instance and it should not only import the characterization design, but all the cohort definitions that were included. There’s nothing that would do the work for concept sets, however. Your best bet (if you want to keep the 2 instances running) would go with the OhdsiRWebAPI R pacakge approach to export-import from old-to-new WebAPI instances.