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

Attribute Assistant in the Enterprise GDB Enviroment

JoeBorgione

For the past several months I have been developing a workflow based on Attribute Assistant in the file geodatabase environment. Now I'm looking at a similar deployment in the enterprise gdb environment.

I understand the issue with the Generate ID table not being versioned but I have a couple of questions:

Must the the Generate ID and the Dynamic tables reside in the same enterprise geodatabase that contains those features and tables I'll be applying Attribute Assistant to?

If not, can I keep the Generate ID and Dynamic tables in a file geodatabase instead?

Are there advantages to keeping the two Attribute Assistant specific tables in the same database as the features and tables and are there distinct disadvantages to keep them elsewhere?

mmiller-esristaff‌

AMuise-esristaff‌

jmward‌

Find more posts tagged with

Local

Accepted answers

MikeMillerGIS

The dynamic value table can be in a FGDB, but for the generate ID table, an edit is required. I sort of recall this needing to be in the same workspace as the edited data. I could run through this scenario in debug mode, but to be honest, if you are using SDE, you need to put your generate ID table in there so that it gets updated correctly between users.

All comments

MikeMillerGIS

JoeBorgione

For this particular application just me, it's just that I manage the point features (common names for CAD) in SDE, so I can replicate them to a fgbd and use them from there. This will make things a little easier for me because I need an alternate name record (separate table) and a common JoinID between the points and alt names. Right now I do it by hand and that pretty much sucks.

JeffWard

Ah, I didn't think about that. How many editors will be editing the data? Could you give each one their own GenerateID table with a unique range of IDs or a text portion to the ID showing who the editor was? Then later you can strip out the text portion?

JoeBorgione

As I sat here fiddling with things, it occurred to me that the Generate ID table gets edited every time it's called upon. So, if I have an edit session open for the Enterprise db feature class, I'm not sure that the the Generate ID table could function properly. I'm going to run a test between two file geodatabses and see what happens.... Be back soon.

moments later....

I copied the original generate id table to a new geodatabse, opened my test mxd and pointed to the new location. No workee: my suspicions above are true. The edit session is open on FGDB_1 which is where my feature class resides. The generate id table resides in FGDB_2. I can add a point to FGDB_1, PointFeature Class but none of the fields that rely the generate id table get updated, nor does the generate id table itself get updated.

JeffWard

Joe,

I don't think you need to have it in the same location. The add-in checks the table of contents for the two tables so you could have them stored wherever you like. The only downside is probably as you are tweaking the DynamicValue table to get the right results. You would have to stop editing your enterprise data and start editing the workspace with the two tables. You could copy the edit data into the same workspace until you have it dialed in and then start editing the real data.

Jeff

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.