How not to lose d-list indexes

[amo77]

Hi,
Hope someone can give me an advice.
For some of our Contributor apps, we have the dynamic d-list as a look-up. This list is updated with the new items by macro from the text file on production server (v7.3 for the moment). At the same time, every time we push design updates from dev server by copying all analyst libraries, this list is being overwritten. We use the workaround of simultaneously updating this d-list both on dev and production server. But, as we know, this proccess is very fragile since the sequence of updates should be strictly identical on both sides, otherwise whole indexing will mess up which will end up losing data in the contributor application.
Each contributorapplication is already using two libraries: application-specific and common library Therefore, we can not just put the d-list into the separate Analyst library (and not copy it during the dev update) because there is a system limitation which prevents using more than 2 Analsyst libraries for a single Contributor application.

So, I wonder if someone can give me any advice on this matter. In general, what are the common practice of handling the dynamic d-lists and theit indexes in such situations? We are going to move to 8.3 soon, would it be easier to handle it in the new version?

Hope my explanations are clear and thanks in advance.

[adityashah27]

Hi,

As far as i know updating dlist items dont mess up indexes (rebuild index files). I think they are for analyst objects and not the object items ( let me know if i need to update my knowledge :) )

I have dealt with dynamic dlists at one of clients.
normally for dev of any prod app, we would first copy the lib from prod to dev and than implement enhancements and bring that back to prod. before doing synch we would do dlist update in prod.
if development takes long time (in weeks) we would bring dev lib to prod and then do dlist updates and then synch with prod app. we never had problems specifically with indexes.
just want to know, do you delete obsolete items (check box) while dlist update?

[ykud]

Hi,
If you're talking about dlist internal IIDs, than I'd recommend using unique names (part of dlist item name that doesn't change at all, like code) to prohibit unwanted changes.

And I'd recommend using deployment packages for dev-prod moving, to ease things.

[amo77]

Hi,

Thanks for your answers. To me it also looks weird, that indexes (iid) are being lost/changed even if the d-lists are updated from the same ascii file. But I had the cases when Contributor did not recognize the updated items during the syncronization though the text parts were exactly the same.
I also agree with the strategy of using deployment packages to move design changes to the production. Unfortunatelly, for the moment we are still on 7.3 which is not supporting this feature, but we are going to start migration to 8.3 soon.

[ykud]

But I had the cases when Contributor did not recognize the updated items during the syncronization though the text parts were exactly the same.

IID changing happens in Analyst, so it's not Contributor to blame. I'd recommend backing up Analyst dlist library before updating it from external source. That will help you in cases you talk about.

[SomeClown]

To elaborate on Yuri's point:
Once an IID value is deleted, it is never re-used.  This means that dropping and re-creating a dlist item will generate a new IID.  This IID provides the link between Contributor and Analyst.  Having a new IID means Contributor cannot find the reference to the old item, and cannot retain the structure and data associated with that dlist item.

[amo77]

Hi,

Yes, IID's are uniquely generated by Analyst when you update a d-list. Other thing is, that they are not generated randomly but based on a particular formula. In other words if you have 2 copies of the same d-list in the different environments and update them in exactly same sequence and from the same file, IID's in these 2 lists will be matching. At least this is what I have been told.
I understand, that this is not the best way of handling the d-lists but this might be the "last resort" solution

[ykud]

Yes, IID's are uniquely generated by Analyst when you update a d-list. Other thing is, that they are not generated randomly but based on a particular formula.

There's no formula, IIDs are just issued sequentially. For example, you have a dlist, where maximum IID currently is 10. Wherether item you add to it, it gets IID 11.

So your description of 2 enviroments will work, if all dlists start the same and are updated by the same elements in the same sequence.