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; } } }

DD: Standalone

LooseCannon

I'm working on a project that requires distributing content: DCRs and binaries from TeamSite to Oracle and trying to determine the best deployment method: DAS or Standalone. Because the deployment requirements are simple: synchronize the Oracle tables with content from staging upon a workflow approval task, I'm leaning towards Standalone. The DD manual states that table "create" privileges are required and when I mentioned this to the DBA he just laughed and said that's not allowed.

Question, is "create" access required? Or can I just create a mapping to tables that he creates? The manual infers the latter but I need confirmation, please.

Thanks.

Find more posts tagged with

Comments

marcussteiner

If you have a dba on the back which does not allow you to create tables then the only path forward for you is to use standalone. DAS requires to creates/drops tables priviliage which i personally find very annoying. specially using the iwov_idmaps table. If you have not too much content then go for standalone and full (against STAGING) or if its a lot of content the go for standalone and differential deployment (STAGING against the last Edition) and snap an edition after each deployment. We've been using that for quite some time now and its just doing the job.

M

cascade.html

cascade.rptdesign

OrdersAfter.html

OrdersAfter.rptdesign

LooseCannon

If you have a dba on the back which does not allow you to create tables then the only path forward for you is to use standalone. DAS requires to creates/drops tables priviliage which i personally find very annoying. specially using the iwov_idmaps table. If you have not too much content then go for standalone and full (against STAGING) or if its a lot of content the go for standalone and differential deployment (STAGING against the last Edition) and snap an edition after each deployment. We've been using that for quite some time now and its just doing the job.

M

Perfect, just what I needed to know. Thanks!