Will Deleting a Personal Dashboard cause TTL problems?

If you delete it in both live and test, then you will be fine.  If you only delete it in live then it will reappear!  For this reason and a bunch of others, I only use t2l in very restricted circumstances and when the timeframe for migration is very short.

My own best practise is to do substantial developments in DEV and then use DT into UAT, together with a document that describes all the manual bits needed.  Once that works I know I have rehearsed and can with confidence do the same into PROD.

If it is a very small change and there is only one administrator and the timescale is short, then I will use T2L.  First into UAT and then into prod.  However since it is currently impossible to reliably lock down the design and admin tools, I will personally only use T2L for a very short (less than 1 day elaspe) modifications.  It's just too easy for a category to reappear, a query to get deleted and so on.

There is an ER for such a locking tool to be provided and if that were available I'd be much keener on T2L.

Once you get used to DT's little foibles it is reasonably easy to use and has the advantaged that you can present to a client a complete list of mods that are going to be made.  With most of our clients this is essential - just having a bit of magic that syncs up sounds good, but in practise is way too dangerous, in my very humble opinion.

Hi,

I am pretty sure that personal dashboards are NOT transferred by Test To Live so deleting it in Live would stick.  In the same way, if a user creates a personal dashboard in Live it will not get deleted by Test To Live.

Personal shortcuts and personal queries are also treated in this manner.

Thanks

Stu

My thoughts and observations are pruely personal Steve, based on our own experiences.  OK I do have umteen years of LDSD experience, but other peoples mileage may vary and both tools have their place.

Once key issues for us is that most of our larger customers wants 'proof' of the modifications migrated to prod.  With t2l I would suggest this isn't possible because of the lack of an LDSD oriented log file.  With DT this is easy.  Just a thought

Hi Steve,

Both tools have their place and it depends on what type of work you're doing and for how long.  Test To Live is great when you are confident there haven't been any design changes made in Live as you get a fast and easy migration of the entire system design.  My personal best practice is to have a three environment process (as DMS) but use Test To Live in both cases.

1. Backup Live database.

2. Restore Live database to DEV environment.

3. Make design changes in DEV ensuring no design changes are being made in Live.

4. Backup Live database.

5. Restore Live database to UAT environment.

6. Perform T2L from DEV to UAT.  Test changes have come through successfully.

7. Perform T2L from either DEV or UAT to Live.

Step 3 is very important - any design changes in Live will impact T2L causing unpredictable results.  Step 6 is also very important but should not take long else you might find Live changes too much by the time you reach step 7.

Design Transfer is great because it lets you pick and choose what to transfer and leaves everything else alone.  If it is not feasible to stop design changes in Live or you just want more control over the migration to Live then DT can be a better option.

Stu

Hi Steve,

That is the list we go from.  If you've had any problems with other areas please let me know and we'll get the document updated.

Thanks

Stu