Sorry, I was forced to post the above picture by Alvin. He wondered why I stopped posting and I think it is only fair to share with you my reason for my absence. Alvin suggested that I stopped posting because of a promotion and I have to admit: It sure feels like a promotion. I got a fancy new title, huge responsibilities a sizeable addition to my workload and very little extra pay. However when I look into those blue eyes I get the feeling it is all worth it and I hope you will forgive me for not posting. In any case the number of visits on my blog has doubled since last year. Which is a testimony to the success of SDL Tridion. To keep this blog relevant I hereby promise to resume posting.
This post is a Response to “Rants on Tridion Implementations” which I ran into on my Sunday evening round of blog reading. In this post Nuno L rants about the burden of fixing broken Tridion implementations. We seem to be in the same business and I would like to share my perspective on this subject. I strongly diasgree with “my job is not always an easy or necessarily happy one”. In addition when I (please read the rant of Nuno first) walk into a project it means your Tridion Troubles are over. I love to fix things that are broken or find a solution to problems other people have given up on. To see despair turn to optimism and see smiles on the customers face always makes me feel happy with my job. Though I have to admit I find that the best part of fixing the impossible is the bragging rights afterwards.
In the language debate I would like to make a stand for reduction in the number of languages/technologies needed to implement Tridion. The cost of maintaining different development environments alone should be enough reason to want to limit the number of languages and technologies.
That said I would also like to vent about the most unintelligible Tridion troubles I have come across: Read more
Recently I had the possibility of fixing one of my customers blueprinting structures which was of questionable quality. The change involved phasing out twelve large publications filled with all types of content imaginable. Of course I used the tips&tricks from a previous post on this topic which handled the ‘unpublishing‘ of content. However I quickly ran into problems which were the result of the time needed by the application to delete the publication.
The publications had been in use for over 4 years and a lot of content had been accumulated in them. In order to be able to delete these publications I had to set a number of timeouts to > 600 seconds. The following might prove useful if anybody attempts a similar clean-up:
- Tridion configuration -> timeout settings ->Seconds before a time out is generated when executing a long query
- MSDTC Admin Tools –> Component Services. Then Right click Computer –> Properties.
- IIS “script time out” error in Active Server Pages.
After these changes I was able to delete most publications and in addition serve a lot of coffee to my colleagues. Unfortunately some publications had not yet reconciled with their fate and refused to be deleted throwing all kinds of incomprehensible errors. I found the following solution to this problem:
<content disapproved by Tridion support>
- Please back-up your DB before attempting the following.
- Run the Stored procedure: EDA_PUBLICATIONS_DELETE using the publication id as parameter.
</content disapproved by Tridion support>