BODS 4.2 and datastores SQL Server 2012 migration - central repo problem

[former_member1095969]

I was wondering whether you have encountered this before:

Setup:

• BODS 4.2
• SQL Server 2012 (datastores only)
• Repos on SQL Server 2008 (as per PAM support)

We upgraded from 3.1 to 4.2 on Data services at same time as upgrading the staging and target DBs to SQL Server 2012.

This has gone ok, and developers local repositories can adjust their datastore configurations to make the datastores SQL Server 2012 and to run code.

The only problem is when we get to checking in/out of central repository or getting latest. Even though I have checked out inc dependents on datastores and done the config flip to 2012, when you check in only the parent datastore checks in changes and the table metadata doesn’t change – hence not checked in (as this is the default way central repo works).

This means when developers then check out/get latest, they overwrite their local repo definitions of tables with 2008 and cannot run anything. They then have to do the config flip to 2008 and then back to 2012 to correct this error.

Is there a way to force check in Central repo table metadata/definitions without any physical changes to schema etc.? Is this stored at DF grain? – as it does list all DFs effected by the config flip.

One suggestion was to enable compatibility at DB level to 2008, but that’s a last resort really. Only other option I can see is checking all the code out and making small changes – like descriptions on tables to then force them to check in as 2012 – we have a lot of code and this is something we don’t really want to entertain.

This is the error message once getting from central with datastore config set as SQL Server 2012:

6460 5400 RUN-050413       20/03/2014 16:38:29        |SESSION JF_TEST_JOB_Live_Insight_CRM|WORKFLOW WF_Initialise_DM_CUSTOMER|DATAFLOW DF_Load_LKP_CUSTOMER_CODES

6460 5400 RUN-050413       20/03/2014 16:38:29        None of the configurations for the specified target table <LI_Extract.DW_STAGE.LKP_CUSTOMER_CODES> contain a database match

6460 5400 RUN-050413       20/03/2014 16:38:29        <Microsoft SQL Server 2012> for the current datastore <LI_Extract>.  For optimal results, always migrate data flows with

6460 5400 RUN-050413       20/03/2014 16:38:29        associated datastore information. NOTE: If you migrated data flows without associated datastore information, import the

6460 5400 RUN-050413       20/03/2014 16:38:29        necessary datastore from the source and add a new datastore configuration to match the new environment. When adding a new

6460 5400 RUN-050413       20/03/2014 16:38:29        datastore configuration, set the "Use values from" option under "Values for table targets and SQL transforms" in the "Create

6460 5400 RUN-050413       20/03/2014 16:38:29        New Configuration" window to use the configuration from which you migrated. You can make the new datastore configuration your

6460 5400 RUN-050413       20/03/2014 16:38:29        default or use system configuration to instruct Data Services to use the new datastore configuration. For more migration

6460 5400 RUN-050413       20/03/2014 16:38:29        information, see the %4 Advanced Development and Migration Guide.

[Former Member]

I've had this error. Here's how I solved it (please note that my target tables were template tables, not sure if this works for actual tables):

1. Delete all of the TARGET instances that table has in your job (deleting source instances will cause other serious problems).

2. Delete the table from the datastore (don't worry, the source instances of this table will stay intact ((if you have any)) )

3. Recreate the table in the associated dataflows, map as before, and refresh the local library; the where used count of the table should be the same as before and you shouldn't encounter errors when running the job.

[former_member1095969]

I have found a way......have to check all the code out from central, do the config switch back to 2008 and then forward to 2012 for any datastores used in that code.

This must mean that the DFs hold the metadata defintions for tables and not the datastores - they just store them.
 
check it all back in - annoying as we have to do it in chunks as too much code but it works.