Try to run first the Cleanup tool to delete the unused objects...

Hi rvgfox

Thanks for your response.

There are no unused objects to remove - I’ve also tried amending the table by adding a new dummy field, deploying and executing the F0111 table, and then removing the dummy field (in an attempt to get the SQL object(s) to rebuild, but still get issue.

If the table it’s incremental, try to do a “full deploy”

Hello @Paul Bridge ,

This error is interesting as you are opening the Error / Warning report right and not running a table.

The SQL cleanup should not have impact on this and adding and removing a column will not trigger the SQL Cleanup as this is with the same table. The SQL clean up tool only shows tables that are not being referenced in the project and not columns in tables.

Did you put some field validations on this table? Otherwise if there are no errors or non of the validations are violated, this report wil be empty.

Do you happen to use the User Defined Funcions? maybe for what ever reason TX checks the project, sees that there is an issue in the User Defined functions which triggers the error?

Hope this helps

= Daniel

Hi rvgfox and daniel

@rvgfox Table is not incremental, but was is a ‘full deploy’? I have already done a ‘Deploy and Execute’ but to no avail.

@daniel I added and removed a column in an effort to get the table sql objects to drop and recreate on the ‘deploy and execute’ of the F0111 table. I do not have any field validations on this table.

How do you mean ‘do I use the user defined functions’ ?

Regards

Hello @Paul Bridge ,

adding and removing a column to a table does not make it so that the table would appear in the SQL cleanup tool. The table will only appear in the SQL clean up tool when the table is deleted from the project. When you add a column TX will make a ALTER TABLE script instead of a DROP TABLE and then CREATE TABLE. And even if it would do that, the table would not appear in the SQL cleanup.

Let go back one step: What is you purpose with going to the Warning / Error report?

Hi,

looking at the error message, the query TimeXtender is running to fill the UI is not working. DSA.F0111_F should be a technical table associated with an F0111 table in your DSA Data Area in a Prepare instance. If you Deploy & Execute that table and uncheck the Differential checkbox, that would fully deploy that table (deleting it and rebuilding it from scratch). If that does not resolve it, it is probably a good idea to submit a support ticket.

Hi @daniel 

Adding and removing a dummy column was not to get the table to appear in the SQL Cleanup tool. I only mentioned this tool as @rvgfox suggested I should try and run the tool to see if that resolved the issue.

I was adding and removing the dummy column, followed by a ‘Deploy’ in an effort to get the table objects to rebuild themselves - what I did not realise was that I also needed to uncheck the ‘Enable Differential Deployment’ box to force a full rebuild on ‘Deploy’ action as suggested by @rory.smith (thanks rory)

I shall try this now.

Hi @Paul Bridge ,

if you add/remove a column TimeXtender will mark the table ‘dirty’ and deploy it differentially as well. It may be that it does not trigger the _F table to be deployed though. Unchecking Differential will cause all involved items to be re-deployed. If doing that resolves the issue and you can generate a series of steps that recreates the error, it would be good to push a support ticket as that implies something in the dependency checking is not 100% correct.

I agree. It is a weird error message for that part of TX. I’m trying to get my head around the fact that it cannot find the column ’DSA’  or it starts checking for User Defined functions (and from you reply it does not seem like you are using them)

Will you let us know what the outcome is?

Thanks!

Hi

So fully deploying the F0111 table in the DSA data area got rid of the original error and instead listed a number of records which were violating the PK in the table. Resolved these PK errors by adding in an additional lineID field available from the source table to force uniqueness. So it looks like it was an obscure message caused by PK violation.

Thanks for the steer everyone

Perfect @Paul Bridge , 

Glad I could be of assistance