web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Synchronization Errors (Cannot drop the index)

(0) ShareShare
ReportReport
Posted on by 195

It looks like a bug. After you run the DTA (Database Tuning Advisor), you cannot synchronize the table without getting errors "Cannot drop the index... because it does not exist".

SQL error description: [Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot drop the index 'LOGISTICSPOSTALADDRESS._dta_index_LOGISTICSPOSTALADDRESS_8_1605632813__K16_K33_K20_K34_K28_K29_1_2_18_19_21_32_', because it does not exist or you do not have permission.

It seems that the DTA creates a lot of 'temporary' indexes to try different scenarios, and even if you never choose to apply these recommendations, AX somehow captures these indexes and will try to drop them with the next synchronization. The problem is these were never created in the first place!! The only workaround I have found is to actually create an index with the same name (it doesn't matter about the fields), then when you run the Sync, it can drop the index and be happy.

It is crazy to produce an error when you can't drop an index that doesn't exist in the first place! Does anyone know where these imaginary indexes are stored? Is there a way to tell AX to not drop indexes that don't exist? How does AX know about the index if it doesn't exist?

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Camilo Virguez Profile Picture
    3 on at

    Hi

    they probably get stored somewhere in the "AOT"...  depends on the versión of AX you have.   Have you checked if the definition of the indexes that is available looking at the table through the AOT?

    CAVS

  • Holli Verhovsek Profile Picture
    195 on at

    No, if the indexes were in the AOT, they would not be trying to drop them during the synchronization. The version is 2012.

  • Community Member Profile Picture
    on at

    I believe the issue isn't so much AX as the culprit, rather AX as the messenger.  The error message is being passed from the SQL server during an attempt by AX to drop indices it does not have permissions to drop; AX did not capture these indices - it is simply requesting the SQL server drop them and it is being denied that permission.

    I'd suggest using DTA to remove all indices after moving those you desire to keep to the AOT, then re-sync the data dictionary again.  

    A way you can test, of course in a non-prod environment, to see if a bug exists in this situation is to create an index on a table directly from the SQL server (using SSMS for example; make sure the first character of the index is a letter) as a user that has equal permissions to the AX database as your AX AOS service account (or, ideally as that same user) and then sync the data dictionary.  

    Then, run a sync on the data dictionary. The newly created index should be removed from the SSMS index list for that table (be sure to refresh your view) now.  In the trcAxaptaSync.log file, you should also see that the index was dropped.

    Hope that helps.

  • HolliV Profile Picture
    235 on at

    It is not that AX doesn't have permissions to drop the indexes, it is that the indexes DON'T EXIST. In fact the only way to work around the error is to manually create an index with the same name (using SSMS) so that it WILL exist when the sync runs and tries to drop it. If the index exists when the sync runs, then it can successfully drop the index. The point is, I shouldn't have to create dummy indexes just so the sync can drop them. I'd like to know where and how these manually or DTA created indexes are stored so that I can remove references to indexes that don't exist anyway.

  • Community Member Profile Picture
    on at

    So, when you look on your SQL server (not in AX at the AOT) using something like SSMS, you do not see these other indexes?  

    I'd suspect DTA will allow you to drop the indexes you do not want, the indexes it suggests and were not selected for use.  

  • 1807Beers Profile Picture
    160 on at

    Got same problem.

    5 indexes for SALESLINE named similar to above.

    Has anyone found where these references are held? 

  • Suggested answer
    Pontus Ek Profile Picture
    70 on at

    I got the same issue. 

    Solved the problem by moveing the data to a temporary db, deleting the tables, syncing and moving the data back. 

    When I was done I found this blog post about the issue. 

    http://intoax.blogspot.com.au/2013/11/database-engine-tuning-advisor-dta.html

  • Darsh Profile Picture
    615 on at

    Hi Bladh,

    i resolved same issue using info on the link you shared.

    Thank you for sharing.

  • Community Member Profile Picture
    on at

    Old post I know, but in case anyone runs into this in the future, I've done extensive research into this.  It's easy to blame SQL as this is a DB function AX is trying to accomplish, but IT IS NOT SQL!  Even our AX vendor immediately blamed SQL until I proved them wrong.  My first direction was to look into SQL Index length limits and make sure AX wasn't bumping up against those, I don't recall exactly what I found out but it was something to the effect that SQL's index length limit is way beyond the point that the error message truncates the index name, by a few hundred characters.  It's the query AX uses to drop these indexes that truncates the names incorrectly and throws an error when SQL can't find the Index in question off of a partial name.

    I started off by simply running the Sync, waiting forever for it to fail then it would list off the indexes it could not drop in the error output, so I would go and just drop those indexes by hand and re-run it and it would complete with only nearly 6 hours of time wasted!  I'd much rather let AX do this as there could easily be a good reason to let AX drop and recreate them as it intended (in other words, no good reason other than just not knowing, but it seems to cause the least impact).

    After a ton of trial and error, I found that keeping index names + table names (Plus additional joining characters like "_" and ".") at or below 90 characters is the magic number, so before I synchronize I run a script I whipped up to rename them.

    Typical disclaimer, this may cause you problems elsewhere, use it with caution (and yes I know this could be a bit tidier and shorter, but I also wanted it to be relatively easy to read):

    ##This Powershell script will truncate all Indexes that have a full name (Tablename.Indexname) and replaces them with a shortened substring of the end of the Index Name

    ## I.E.     INVENTITEMLOCATION.CST_INVENTITEMLOCATION_WMSPICKINGLOCATION_INVENTDIMID_DATAAREAID_PARTITION

    ##Becomes:      IDX_INVENTDIMID_DATAAREAID_PARTITION_20171221103229

    ##I used the substring from Right to left to ensure uniqueness in the index name, this isn't perfect but it works.

    $PRODSQLInstance = 'YOUR_SQL_SERVER_HOST_HERE'

    $PRODSQLDBName = 'YOUR_CUSTOMER_DB_NAME_HERE'

    $IndexMaxChar = "90"

    $AXSqlServer = $PRODSQLInstance

    $SQLGetIdxScriptblock = @"

    use $PRODSQLDBName;

    SELECT DB_NAME() AS Database_Name

    , sc.name AS Schema_Name

    , o.name AS Table_Name

    , i.name AS Index_Name

    , i.type_desc AS Index_Type

    FROM sys.indexes i

    INNER JOIN sys.objects o ON i.object_id = o.object_id

    INNER JOIN sys.schemas sc ON o.schema_id = sc.schema_id

    WHERE i.name IS NOT NULL

    AND o.type = 'U'

    ORDER BY o.name, i.type

    "@

    $AllSqlCmd += $SQLGetIdxScriptblock

    $SQLIndexesAll = Invoke-Command -ComputerName $SQLServer -ScriptBlock {

    param($SQLGetIdx_Query)

    sqlps -NoLogo -Command {

    param($SQLGetIdx_Query)

    invoke-sqlcmd -Query $SQLGetIdx_Query -querytimeout ([int]::MaxValue)

    } -args $SQLGetIdx_Query

    } -ArgumentList $SQLGetIdx_Query

    $VerboseMsg = "Indexes Found: "+$SQLIndexesAll.count

    Write-Verbose $VerboseMsg -Verbose

    $SQLIndexesRenamed = $SQLIndexesAll | ?{(($_.Index_Name | Measure-Object -Character).Characters + ($_.Table_Name | Measure-Object -Character).Characters + 1) -gt $IndexMaxChar}

    $VerboseMsg = "Indexes Found exceeding the max char limit for AX DB Sync: "+$SQLIndexesRenamed.count

    Write-Verbose $VerboseMsg -Verbose

    if (($SQLIndexesRenamed.count) -ge 1){

    $SQLRenameIdxScriptblock = @"

    use $CustDestDBName;

    "@+"`r`n"

    $SQLIndexesRenamed | foreach {

    $VerboseMsg = "Generating Index Rename SQLCMD for - "+$_.Table_Name+"."+$_.Index_Name

    Write-Verbose $VerboseMsg -Verbose

    $CurrentIdxName = $_.Index_Name

    $CurrentIdxTable = $_.Table_Name

    $CurrentTimeStamp = $(Get-Date -format 'yyyyMMddhhmmss')

    if (($CurrentIdxTable+"."+"IDX_"+$CurrentIdxName+"_"+$CurrentTimeStamp).Length -ge $IndexMaxChar){

    $NewIdxName = "IDX_"+($CurrentIdxName).Substring(($CurrentIdxName.Length) - ($CurrentIdxTable.Length) - ($CurrentTimeStamp.Length))+"_"+$CurrentTimeStamp

    }else{

    $NewIdxName = "IDX_"+$CurrentIdxName+"_"+$CurrentTimeStamp

    }

    $VerboseMsg = "New Index Name - "+$NewIdxName+"`r`n`r`n"

    Write-Verbose $VerboseMsg -Verbose

    $SQLRenameIdxScriptblock += @"

    EXEC sp_rename N'$($_.Table_Name).$($_.Index_Name)', N'$NewIdxName', N'INDEX';

    "@+"`r`n"

    }

    Invoke-Command -ComputerName $SQLServer -ScriptBlock {

    param($SQLRenameIdxScriptblock)

    sqlps -NoLogo -Command {

    param($SQLRenameIdxScriptblock)

    invoke-sqlcmd -Query $SQLRenameIdxScriptblock -querytimeout ([int]::MaxValue)

    } -args $SQLRenameIdxScriptblock

    } -ArgumentList $SQLRenameIdxScriptblock

    }

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans