I can confirm that I am experiencing the same behaviour (although it hasn't yet prevented me from saving). I'm glad I didn't do this for all 1500 sites yet. I assume that even though it doesn't interrupt normal use of the db, the presence of four or five copies of each grid square in the list  might impact negatively on performance when doing some kinds of spatial queries on a large dataset (since there will be many more sqares to check against).

One strange aspect to this which I did notice is that after I had extracted the grid squares for a couple of location boundaries put one location into edit mode and then saved again (to see if recorder would stop me as it did Charles), it allowed me to save (although nothing had changed), but when I examine the content of the GRID_SQUARES table, I find that the entries for that location all had the CHANGED_BY and CHANGED_DATE fields set (to me at the time I saved).

Clearly these fields should only be set after an edit which makes changes and it leaves me wondering if this happens with other tables in the db (I have not checked).

I know recorder does not make much use of these two fields, but they can be very useful to the database administrator and it would be good if they reported edits correctly and consistently across the database. It would actually be even more useful if (for at least the major tables?) there was a mechanism for viewing the information they hold from within recorder, although I appreciate that this would represent a fairly major change to the system for little return for many users.

While I am on the subject, I must say that it is a shame that the ENTERED_BY and CHANGED_BY (and corresponding date fields) are managed by the Recorder UI, rather than by SQLServer internal triggers. I guess this is a hangover from the Access database days when triggers were not an option. . There have been many occasions when I have needed to carry out complex updates through the Access database or through Management Studio (because I didn't have time to develop an XML batch update for a very specific once-only task). It is really annoying on those occasions when I forget to set those fields. My fault though & I guess I need to be more careful.

yeah I had thought of the NBNUser issue John. I was just having a moan for the sake of it really. I know it's too fundamental a change to be likely to be implemented.

Interested to hear your thoughts though. Personally I have not found the trigger approach to be particularly slow when I have used it for other applications, but I admit I have never tried it with a very large dataset.

Anyway I have given the map tool another day of my time, trying to convince myself that it's worth the effort of setting it up. Yet again I have come away thinking naah, can't be bothered, not if I have to import all the thousands of polygons onto each workstation. I'll go back to my (very long-term) project of developing an alternative.

That's what is supposed to happen John, but on our system no.  We have all sorts of exceptions occurring whenever we try the recorder maps on some of the workstations and I haven't found myself inclined to make them work properly yet. If I ever get round to sorting out everyone's machines properly, maybe I will think again about this.

As for the development task, well I agree that from scratch it would be huge, but I have an almost complete application, currently in vb, which uses mapinfo integrated mapping and which tightly controls the kinds of edits which can be done on our boundary map layers, in the process extracting attribute data from recorder 6 and inserting some data back (e.g. site areas etc.)

Using MapInfo in this way dramatically reduces the amount of development work necessary and provides the kind of high end tools that we need (although obviously it requires a mapinfo licence). I anticipate that within a few weeks this tool will become our main means of editing site boundaries and doing all sorts of other stuff.

Once the creases are ironed out, I will move onto the next stage, which will be to try to make it into a Recorder addin, although I may have to use something a bit cleverer than vb for that since I don't know if vb can create activex conrols any more. It's an interesting challenge, but everyone needs a hobby no?

Oh and I have just noticed that in Charles original post he was refering to duplication only of the 10km grid squares. Here it is happening with 100m grid squares (I am trying to get rid of the 10km squares as I don't think they provide very useful validation)