ERROR: Could not drop object '<temp table>' because it is referenced by a FOREIGN KEY constraint. Could not apply schema

(0) Share

Report

Posted on by Daniel Zook

847

We use AXUtil to deploy new code to AX TEST and PROD environments. We also have an UpgradeTest environment, and when I test deploying the latest model store file, the AXUtil fails with this message while attempting to apply the temporary schema:

C:\Program Files\Microsoft Dynamics AX\60\ManagementUtilities>AXUtil.exe importstore /db:LHA_2012R2_UpgradeTest_model /s:ax3-04 /apply:TemporarySchema

AXUtil 6.2 - Microsoft Dynamics AX Admin Utility (6.2.1000.1437)

The AXUtil command was started in the mode: importstore.

Working against model store ax3-04/LHA_2012R2_UpgradeTest_model.

ERROR: Could not drop object 'tmpbd43244fd0084a7f8b808ff5862ee9ca.ModelGroup' because it is referenced by a FOREIGN KEY constraint.

Could not apply schema

Has anyone seen this before? Any suggestions on what to do about it, or how to trouble-shoot?

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (1)

Daniel Zook 847 on at

Like (0)

Report

Running SQL Profiler reveals that these are the last few SQL commands that are run right before it fails...

exec [dbo].XU_CreateSchema @schemaName=N'tmp2b9c85b6e00c405b867b42c35bfa647e'

exec [dbo].XU_TransferObjectsToSchema @SourceSchema=N'TemporarySchema',@TargetSchema=N'dbo',@BackupSchema=N'tmp2b9c85b6e00c405b867b42c35bfa647e',@OutputBackupSchema=0

exec [dbo].XU_DropSchema @schemaName=N'tmp2b9c85b6e00c405b867b42c35bfa647e'

The schema name in the profiler trace matches the name in the error message:

ERROR: Could not drop object 'tmp2b9c85b6e00c405b867b42c35bfa647e.ModelGroup' be

cause it is referenced by a FOREIGN KEY constraint.

It seems odd that this error does not happen in our TEST environment. Is the error message a red herring?

Was this reply helpful? Yes No
Verified answer

Daniel Zook 847 on at

Like (0)

Report

I eventually found the problem. There is a bug in the older versions of AXUtil. Replacing the following files with the 6.2.2000.305 version solves this problem.

axutil.exe

axutillib.dll

axutil.powershell.dll

Microsoft.Dynamics.Framework.Deployment.Portal.dll

These are in the \Program Files\Microsoft Dynamics AX\60\ManagementUtilities folder.

Was this reply helpful? Yes No
@rp@n 30 on at

Like (0)

Report

Hello Daniel

I hope you are doing good.

I got the same error as I explained above.

Could you please let me know details step by step. So, that will proceed accordingly.

It's very urgent. Please help me on this.

Thanks!

Was this reply helpful? Yes No
@rp@n 30 on at

Like (0)

Report

Hello Daniel

I have done the below steps for IMPORTING Model store :

Initialize-AXModelStore -Server DEV001\DEV1 -Database MicrosoftDynamicsAX_model -AOSAccount "AOS_DEV" -SchemaName DEV

initialize and schema creation is the first step : DONE

Import-AXmodelstore -Server DEV001\DEV1 -Database MicrosoftDynamicsAX_model -SchemaName DEV -File 'C:\Backup\TEST_ModelStore\TST.axmodelstore' -Details –Verbose

importing modelstore to the schema which we created in the step 1 : DONE

Import-AXmodelstore -Server DEV001\DEV1 -Database MicrosoftDynamicsAX_model -Apply DEV -Details –Verbose

applying schema to the database :Got an error

Could not drop object '<temp table>' because it is referenced by a FOREIGN KEY constraint. Could not apply schema

Please help me on this.

Thanks!

Was this reply helpful? Yes No
Daniel Zook 847 on at

Like (0)

Report

What version of AXUtil are you using?

Was this reply helpful? Yes No
@rp@n 30 on at

Like (0)

Report

Hello Danial,

I am using below version.

MS Dynamics AX 2012 R3

Kindly let me know if you need any more info.

Please give me more shed on this.

Thanks!

Was this reply helpful? Yes No
Suggested answer

Daniel Zook 847 on at

Like (0)

Report

I'm on the same version of AXUtil in our R3 test environment, and it is working just fine,

However, I just noticed a couple things from your other posts:

1. You appear to be using PowerShell. I can't vouch for how that works (I imagine it should, but I have no experience deploying model store files using PowerShell). When we deploy code we always use AXUtil instead.

2. You appear to be starting with an empty model store, since you called Initialize-AXModelStore first. I've never tried that. I always install the target AX instance from setup.exe first, and then use our script to deploy the updated model store after that.

Hope this helps. If not, you may need to start your own forum post and ask others for assistance, or contact an AX partner.

djz

Was this reply helpful? Yes No
@rp@n 30 on at

Like (0)

Report

Thanks Danial

Could you please let me know the exact steps and command which you applied. So, I will try accordingly

Please give me more shed on this

Thanks!

Was this reply helpful? Yes No
Daniel Zook 847 on at

Like (0)

Report

We use the AXUtil.exe program in a command line script, like so:

1. Start with an existing model store (not an empty one). For example, create a new AOS instance (e.g. QA), and then backup your TEST model store db and restore over the new AOS instance model store.

2. Use AXUtil to export the model store from your build environment: AxUtil.exe" exportstore /file:MicrosoftDynamicsAX /db:<ModelDB> /s:<DEVSQLServerInstance>

3. Create temporary schema in QA environment database: AxUtil.exe schema /db:<ModelDB> /s:<QASQLServerInstance> /schemaname:TemporarySchema /noprompt

4. Import the model store you exported in step 2 into the temporary schema: AxUtil.exe importstore /db:<ModelDB> /s:<QASQLServerInstance> /file:MicrosoftDynamicsAX /idconflict:overwrite /schemaname:TemporarySchema /noprompt

5. Stop AOS(s)

6. Apply the temporary schema: AxUtil.exe importstore /db:<ModelDB> /s:<QASQLServerInstance> /apply:TemporarySchema /noprompt

7. Remove the temporary schema: AxUtil.exe schema /db:<ModelDB> /s:<QASQLServerInstance> /drop:TemporarySchema /noprompt

8. Start AOS(s)

9. Synchronize the database from the AOT, deploy reports, etc.

Was this reply helpful? Yes No