Trimble Business Center

Hello,

Our process for daily TBC to Access, then Access to TBC involves having a blank Access template file with a complete Access job file linked into the blank one.  Apparently, when doing so, Access doesn't recognize all the points that exist in the complete and linked Access file.  For example:

1. Day file: We have a blank Access job file with no data in it except for the correct settings and coordinate system information.
2. Master file: We have a Access job file with all of the current existing point file data. 
   1. Let's assume for this exercise that this master Access job file has point 0001 - 5021 defined within it.
3. We open the day file.
4. We link the master file into the day file
5. We make our set up and go to work.
6. The field crew was under the wrong impression that points above 4999 had never been stored before and that point 5000 was the correct location to store and go from.
7. The happily do so and do not receive a warning that point 5000 exists, would they like to choose a different point.  The continue their work and.
8. At the end of the day when we get this back to TBC we notice that we have point conflicts between previous point 5000 - 5021 and the same collected today.  So we renumber those points.
9. Pretty easy.  Except when doing stake out and the stepped on (or duplicate points) are as staked points.
10. In the same situation above, except the field work was a staking job, when you import the points into TBC you get as staked points created and the duplicate point number automatically get a suffixed of -1 (most of the time, assuming this is the first instance of that duplicated point).
11. So now you have these as staked points of 5000-1, 5001-1, 5002-1, 5003-1, etc.
12. I will manually rename these to an open location and sometime we have to go back and update the lath. Shoot.
13. What I just noticed today was when I renumber then and then convert as staked points, they revert back to their original point number.  So when I change as staked Point ID from 5000-1, to the next open number which is going to be Point ID 5075 for this exercise and then I convert as staked points, the raw data for As Staked Point ID 5075 doesn't create a regular old Point ID 5075, it reverts to placing the raw data under regular old point 5000.  This seems wrong to me.

Has anyone else seen this and have any thoughts?  Also, you can then change the Point ID for the newer raw data line that is under regular old Point ID 5000 and assign the new 5075 point ID, but when you select point 5000 the properties tell you that it comes from the newer raw data import.  It break the tracking back to the correct raw data entry file (.jxl or .job file depending on your preference).  That seems wrong too.

Wow! Big post.  Sure am excited for some help here.

Hello Clayton,

never bothered much with converting as-staked points before. And with our naming convention we basically can't end up with duplicates, so I never had to rename any of them.

I can see what you describe in 5.90 and 2024. So, it's like this since quite a while. It seems strange/wrong that it does overrule your editing with the original point number. Not sure what the reasoning behind it is. Maybe none at all. I've come across so many shortcomings with drafting in the last two days that this is just another head banger.

You're probably best off talking to your dealer. If they open an official ticket, we may get some answers.