Hi Simon and Matt,

During my work on the Recorder-D project (adapting and translation Recorder and the NBNDatabase to the needs of German naturalists) I had been looking for a background possibility to link admin-areas or locations to imported shape files (e.g. German 'Länder' or other admin areas to their shapes) at the beginning of my work 2 ½ years ago. I didn't proceed in this because other problems were more significant.

But what I found out was, the gdb files are dBASE-Files with "wrong" extention. It was not possible to open this files with Borland's dBASE 5 (Win 16) or Ashton Tate's dBASE 4.2, because both will recognise the mdx index file as corrupt (dBASE 5 will open the dbf in read-only mode).
But *gdb-files can be opened with some of the more recent dBase editors, for example Alexey Dolgachows "DBFNavigator" (download link: http://nwvault.ign.com/fms/Download.php?id=19598) or the Grigory Filatov's famous DBFView, which is bundled with the Harbour-MiniGUI Project (Harbour MiniGUI 1.4 or 1.5 Extended Edition, http://sourceforge.net/project/showfiles.php?group_id=135924&package_id=268845&release_id=625319).

It seems that broken links can be fixed by editing the *.gdb file with a dBASE-editor, which may be more user friendly than a hex editor. When I opened a *.gdb File (in DBFNavigator you can open the file without renaming to *.dbf), I found 4 columns:
ID, STACTIC_ID, LOCATN_KEY, LOC_BD_KEY. I can edit the values of the Locatn_key and Loc_bd_key columns to fix the problem as Simon described. But I wonder whether I will get a problem with the mdx-index file, because I could not find out which fields are indexed in this file (If this would be a problem, it will also occurred after editing this file in a hex editor as well)?

In the LOCATN_KEY Field Recorder stores either the LOCATION_KEY or the ADMIN_AREA_KEY. If an ADMIN_AREA_KEY is stored, the value has a prefix (#).
In the LOC_BD_KEY Field the LOCATION_BOUNDARY_KEY is stored, if a Location is linked to the line or polygon object. But what is stored, if an admin area is linked to it? The difference between ID and STATIC_ID I couldn't found out.

Motivated by the recent discussion in the forum I resumed my tests on linking Polygon/Line objects to locations and admin areas. So I found out:

- It is not possible to link a polygon or line object both to an Admin area and a Location (This makes sense, because its very rare that Locations and Admin areas have the same boundary).
But when I added a polygon object, which has already been linked to an admin area to a Location the existing link was replaced by the location link without any warning message!!

- In one of my map screens a created an object layer and added two polygons. I linked one polygon to a location. After saving I opened the object sheets *.gdb file in DBFNavigator. For every polygon a record was created, so I got 2 records. ID and Static ID had identical values. As I expected one of the records got the Location_Boundary_Key value and Location_key value of the location, to which it was linked.

- I wrote this values in the appropriate fields of the "unlinked" record and deleted them in the "linked" record. Saved and closed the gdb file.

- I switched to Recorder and tested what happened: I opened my map and selected the previously linked polygon. I selected "Associate Boundary" and got the Associate Boundary dialogue. I leaved this dialogue with "Cancel". I selected the other polygon, clicked Associate Boundary – and got the location screen with the location (as I have expected).

- I closed the map window, selected my test location on the Location window. Then I selected "Find on map" from the context menu: Recorder opens the map window and selects a polygon – but the originally linked polygon! Did I overlook something?

(Please excuse my sometimes very "German" English)

Kind Regards,
Thomas