***Note: This post is for knowledge sharing only, we are not asking for a solution as there is already as case in which Symantec is researching for a fix.***
We recently upgraded our CCS 10.5.1 Envioronment to the 2012-04 PCU.
Shortly after we noticed that some of our Data Collectors Module scheduled task list's failed upon exporting to their designated locations.
Symptoms:
Some tasklists contain an unattended export option fail to export with example error (removed account names and files names).
Export Grid: Excel 97-2003 export to Disk file; Export filename=D:\Program Files (x86)\Symantec\RMS\Data\ - Failed.
Error in Exporting: Unable to export to local target [D:\Program Files (x86)\Symantec\RMS\Data\\Personal\
Either the destination path does not exist or the CCS JobProcessor's user account does not have permission to access it. Additional diagnostic information may be present in the following error text from the export format: Unable to open a record-set from the result-set database (\Data\BVT_5622855d3f3c46b7ae41a569c0ce5b26) due to error (Can't open recordset: Syntax error in ORDER BY clause.). The query-string used was (SELECT * FROM Table1 order b).
We have also been able to reproduce this issue by exporting manually without a tasklist to any OLE and or .CSV format on those queries affected.
Not all queries and tasklists are affected and they seem to amongst various data sources and fields. One Data Source and Field we have identified is the Unix Users datasource with the field (machine name short). Any query with that field experiences this error. For example if you used the defaults Unix Users fields of (Machine Name, User Name and User Database) you will not experience the error when exporting, however when you switch the Machine Name field with Machine Name Short, the referenced error will occur either by means of a manual .csv or .ole export or via any tasklist export of any type of format.
We also noticed but have not been able to replicate that some of our affected queries do not have their historical data sets in place any longer. This is not across the board, but on at least one or two of the affected queries, the previous historical data is no longer in place.
Reference: Case 03486552