The YouTube video posted earlier covers the basic installation of the Trimble Positions Desktop add-in and the creation of the desktop, or office-side, database. However, we think it would be useful to have a brief discussion about what this database is, especially because it’s one of the key differences with Trimble GPS Analyst.
In short, the desktop database is a repository where we store the ‘operational’ data for the Trimble Positions desktop components: the Desktop add-in and the Mobile Project Center extension. This includes field configurations, post processing profiles, the base station list, project definitions (e.g., name, editable layers, accuracy thresholds, and GNSS metadata transfer fields), and the session/feature/position data within each project. It is not a geodatabase nor is it even really a spatial database. Other than log files and .NET-related settings files (for persistence), and obviously your GIS data, the desktop database is the only place where Trimble Positions will store data on the desktop.
When you ran the Trimble Positions Configuration Tool after installation, you were essentially doing 4 things, assuming you selected the default option:
- Creating an empty Jet/MDB database
- Creating an ODBC entry for this new database
- Connecting to this new database through ODBC and creating schema (tables) in it
- Storing the connection information in a configuration file that is shared between the Trimble Positions components on the desktop
With the options provided in the Configuration Tool, you also have the ability to use any ODBC data source as the repository for the desktop database schema. In order to use this option, you would likely first have to setup a database in the RDBMS platform of your choice (e.g., Microsoft SQL Server, Oracle). Then, you could run the Configuration Tool and select the radio button for ‘I will setup a database connection myself’. This will enable the ‘Manage…’ button that launches the ODBC Data Source Administrator application (the 32-bit version that comes with Windows). Here, you can create system DSN entries for your ODBC database. It’s a bit outside the scope of this blog to cover the multitude of DSN/ODBC entries, but there is a wealth of information on the Internet for connecting to the common ones (SQL Server, Oracle). Typically, you’ll first need to have the drivers installed on your desktop that match the version of the database you’re trying to connect to (e.g., SQL Server Native Client). Once you’ve created the new system DSN entry, you’ll see it in the select list within the Configuration Tool. Select it and click ‘Apply’ to build the schema and you’re pretty much done.
Some of you have asked if you can use an enterprise (formerly ArcSDE) geodatabase as a repository for the Trimble Positions desktop database schema. Although technically possible, it’s not recommended. It’s just not good practice to have tables floating around your geodatabase that aren’t really part of the geodatabase. Someone could easily make the mistake of deleting them or registering them with the geodatabase, both of which would cause problems. If you already have enterprise geodatabases, then you already have an RDBMS platform and it would be prudent just to create a new database for Trimble Positions. For what it’s worth, both Microsoft and Oracle have free versions of their database platforms that can be used for this purpose.
This brings up the logical question…when would you want to use a custom ODBC data source as opposed to the default Jet/MDB data source? The most obvious use-case would be the desire to share project definitions and data, as well as post processing profiles, between users on different desktop machines in different locations (to share the workload). Granted, Jet/MDB databases can be shared via UNC path and accessed by multiple users. Given the sharing model and network behavior of Jet/MDB database access, this may work well within a single office or several well-connected offices, but may start to break down beyond that. So a custom ODBC data source using an enterprise RDBMS such as SQL Server or Oracle may be more appropriate in diverse, enterprise environments. Another benefit of enterprise RDBMS platforms is the inherent support for backups, manageability, and high availability. Although scalability is often cited as another key benefit, we don’t anticipate your Trimble Positions desktop database growing large enough for that to become an issue.
However, there’s another use-case to consider in large organizations. What if there’s a bunch of small field offices that work locally but have some centralized management functionality? In this case, you could work with Jet/MDB databases and have someone create a seed database that contains shared field configurations and post processing profiles. This seed database could be shared with the field offices where people could access it locally.
In any event, the choice is yours.