Autodesk GIS Design Server
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
*Mena, Antoni
Intermedia te commit
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
73 Views, 0 Replies
10-23-2002 07:13 PM
Hi,
We have found a problem trying to do an intermediate commit in GML.
First of all, we create a version 1 depedent on versión 0. Then, we create a
new version 2 dependent on the previous version 1.
Setting the version 2 as the active version we create a new feature with
feat_num 45. Then, in the DB, we obtain two new records in the g_master
table:
- feat_num: 45 plan:0 version: 2 with coordinates
- feat_num: 45 plan:0 version: 0 without coordinates
In the related data attribute table we obtain two new records with keys:
- feat_num: 45 g_version: 2 g_next_version: ""
- feat_num: 45 g_version: 0 g_next_version: -2
If we commit the version 2, we have only one record in g_master table
- feat_num: 45 plan:0 version: 0 with coordinates
and another record in the data attribute table
- feat_num: 45 g_version: 0 g_next_version: ""
So the commit has finished correctly.
But if, instead of doing the direct commit, we try to perform an
intermediate commit
to the version 1, the result is completly different.
In step 1, we make a commit of version 2 to version 1. (We have previously
made the version 1 active)
Then we can see that there is only one record in g_master table
- feat_num: 45 plan:0 version: 1 with coordinates
- and another record in the data attribute table
feat_num: 45 g_version: 1 g_next_version: ""
If we now perform a commit of version 1 (to version 0, obviously), our
register doesn't go to version 0.
Since there is only a row for the feature 45 in version 1 and there isn't
the associated rwo for version 0, the commit doesn't work. The
feature 45 never goes to version 0, staying forever in version 1.
Does anyone know a "workarround" to solve this bug in GML processor?
Thank-you in advance.
We have found a problem trying to do an intermediate commit in GML.
First of all, we create a version 1 depedent on versión 0. Then, we create a
new version 2 dependent on the previous version 1.
Setting the version 2 as the active version we create a new feature with
feat_num 45. Then, in the DB, we obtain two new records in the g_master
table:
- feat_num: 45 plan:0 version: 2 with coordinates
- feat_num: 45 plan:0 version: 0 without coordinates
In the related data attribute table we obtain two new records with keys:
- feat_num: 45 g_version: 2 g_next_version: ""
- feat_num: 45 g_version: 0 g_next_version: -2
If we commit the version 2, we have only one record in g_master table
- feat_num: 45 plan:0 version: 0 with coordinates
and another record in the data attribute table
- feat_num: 45 g_version: 0 g_next_version: ""
So the commit has finished correctly.
But if, instead of doing the direct commit, we try to perform an
intermediate commit
to the version 1, the result is completly different.
In step 1, we make a commit of version 2 to version 1. (We have previously
made the version 1 active)
Then we can see that there is only one record in g_master table
- feat_num: 45 plan:0 version: 1 with coordinates
- and another record in the data attribute table
feat_num: 45 g_version: 1 g_next_version: ""
If we now perform a commit of version 1 (to version 0, obviously), our
register doesn't go to version 0.
Since there is only a row for the feature 45 in version 1 and there isn't
the associated rwo for version 0, the commit doesn't work. The
feature 45 never goes to version 0, staying forever in version 1.
Does anyone know a "workarround" to solve this bug in GML processor?
Thank-you in advance.

