nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Populate Admin Database

System

This project is winding down and they're now realizing that there's no interface for users to work with the admin database (the one that populates drop-downs, etc. in the DCTs). I'm sure other organizations have faced this issue - what solutions work and how well?

Since users are already getting trained on DCT usage and we have a custom process that adjusts database records based on DCR XML I was thinking of having users create DCRs to affect the tables. Some of the tables are just flat (to populate a drop-down, such as customer segment) and some have have parent/child relationships (the selection in one drop-down controls the values in a second drop-down, such as selecting a software title and then selecting one or more versions of that title), but that's about as complex as it gets. I would rather not write a DCT for each table - at the most two seems good (one for simple tables, one for related tables - but even that can probably be avoided just by hidding the child replicant). I was thinking there could be a drop-down at the top where they select which table the DCR is associated with (which names the DCR and becomes readonly on save/open), then a replicant for the parent records (one field for ID/value autopopulated and one for the drop-down label/text) and another replicant for the child records (same fields).

Find more posts tagged with

Comments

fish

I hope I'm understanding you correctly ...
Can you not just have DCR(s) that manage the admin tables and use datadeploy to manage the DB population?
e.g. one DCT and DCR for that matter for 'customer segment' and populated via autoincremented tables as you've mentioned , etc

Steve North
Interwoven Consultant
Sony - Europe

Migrateduser

Thanks for the response. They chose to go with a custom data loading process here instead of DataDeploy (which isn't really a decision I would argue with), so building in DataDeploy at this point might not be reasonable. It seems like a similar approach could be used with the custom data loader but it also seems like there are some issues I'm not seeing.

ts_user

Is ADMIN database only used to populate the DCT's? If this is the case then you can create Admin DCT's for creating DCR's which can then be used to populate your DCT's. All information will be stored in TeamSite which is good because all information is always versioned.

Thanks.
~tsuser.