I am building a file geodatabase using ArcGIS. The gdb is going to be distributed to dozens of 'stand alone' machines. End users are expected to populate the gdb with data. End users do have ArcGIS but vary widely in thier technical savvy. Depending on their business needs, different users will populate different subsets of the database (a few potential combinations). I would like to expose the minimum number of fields to each user while they are entering their data.

I can think of two general solutions, but I don't have a good handle on the pros/cons of each. I'm hoping for feedback in the form of relative difficulty, relative benefits, or better yet... a better solution.

1) ArcGIS "Add-in" form built with Visual Studio
2) Form built outside of ArcGIS (Access, Python/Tkinter, or Internet based) and imported into the end user's gdb from a script within ArcMap

I am not clear what the form/script is supposed to do? Can you please elaborate.
–
GuidoSOct 8 '10 at 19:50

The form is intended to show an end user only those values from the gdb that they care about. I am trying to figure out what my options are for creating that form. My gut is telling me to go with option 1 above and I'm hoping for input before I start a brand new learning curve (C#)
–
BrianPeasleyOct 8 '10 at 20:22

1

Writing a GP tool and just using the generated dialog isn't enough?
–
Jason ScheirerOct 9 '10 at 4:37

If you go with 1) remember to target the .NET 3.5 framework
–
patrickOct 11 '10 at 17:01

Do you want users to add spatial data too? Or is it just fields associated with features?
–
djqDec 10 '10 at 21:39

5 Answers
5

Apparently there is no magic bullet for this... Maybe an opportunity for one of you entrepreneurial types?

If I understand the comment from Jason Scheirer above, a fairly simple solution is to write a few GP tools:

1) Make copies of all non-spatial gdb tables
2) From the copied tables, delete attributes that should not be exposed to "Client A"
3) Write an "add record" GP tool for each of the table copies that "Client A" needs
4) Repeat steps 1-3 for each unique set of attributes that you want to expose (Client B, C...).
5) Bundle the GP tools into a tool box for each custom view of the gdb

Cons: The UI won't be pretty & the housekeeping will be tricky business (a change to the gdb, will need to be reflected in all table copies).
Pros: The tools are at hand, I can get busy tomorrow.

Your comment made me realize that I left out a key factor in my original description. I'm building the gdb schema and I want the end users to populate it with data... So no, this suggestion won't work for me.
–
BrianPeasleyOct 12 '10 at 0:02

In addition to symbology etc. layer files save the state of shown/hidden fields of the attribute tables. So if the downstream editors are comfortable entering data in table view, set the table display properties to hide the unnecessary fields, save a layer file, and pass the layer file on. It's also possible to set font size, column width, and few other things this way. The same theory applies to .mxd's also.

Note: I'm going from memory. It's possible that when one starts an edit session the hidden fields are shown. So test first.

One approach is to create a standalone table in an MS-Access* mdb and Join it to the spatial layer(s). You are then free to use all the standard Access tools for creating forms, queries, etc. on the standalone table. The disadvantage of course is that people can't see the geometry at the same time (from the forms interface), so this will only work in some circumstances.

i dont know if anyone here has really explained a method of joining data but, by adding data from your gdb and if you are looking to condense it to a smaller output/input i would use the joining tool but only the information that is relative to that layer so that it may make them smaller and less confusing to the user and the person using the program.