5

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

5
  • I am not clear what the form/script is supposed to do? Can you please elaborate.
    – GuidoS
    Oct 8, 2010 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#) Oct 8, 2010 at 20:22
  • 1
    Writing a GP tool and just using the generated dialog isn't enough? Oct 9, 2010 at 4:37
  • If you go with 1) remember to target the .NET 3.5 framework
    – patrick
    Oct 11, 2010 at 17:01
  • Do you want users to add spatial data too? Or is it just fields associated with features?
    – djq
    Dec 10, 2010 at 21:39

5 Answers 5

1

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.

1

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.

0

Could you simply turn off the unneeded fields and then let them use the Identify tool? Obviously, this solution is a bit of a hack and doesn't scale well.

1
  • 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. Oct 12, 2010 at 0:02
0

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.

0

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.

*The same principle can be applied to Excel, Oracle, SQL-Express,...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.