r_version_label changes after 10 versions

BTW, here's the DQL... I run the same thing every time I load a version into DM and it works every time until I hit v10.0:

SELECT object_name,r_version_label, r_modifier, r_modify_date,r_object_id,r_object_type,r_lock_owner,owner_name,r_link_cnt,r_is_virtual_doc,r_content_size,a_content_type,i_is_reference,r_assembled_from_id,r_has_frzn_assembly,a_compound_architecture,i_is_replica,r_policy_id,wind_desc, my_class, my_group, my_type FROM my_repository (ALL) WHERE (a_is_hidden = FALSE) and FOLDER('/Projects/888812345',DESCEND) order by my_class asc, object_name asc, r_version_label desc ENABLE(NOFTDQL)

Again, versions 1-9 show up like this:

9.0,CURRENT

...

2.0

1.0

When I hit version 10, the results mysteriously change to this:

CURRENT

9.0

8.0

...

3.0

2.0

10.0

1.0

Thanks for any ideas!

Bret

it is sorted just using characters instead of numbers.

In your DQL statement, try sorting by r_object_id instead of r_version_label.

However r_object_id's are not guaranteed to be sequential. You can try it but in a distributed environment it can still go wrong.

The problem is that version_labels are not a number but a string. Otherwise 1.0 would simply be shown as 1.

Jorgen is right (forgot distributed env)

How do you need that proper sorting ? In your own app ? if yes, you could build your own sorting algorithm to handle that properly. A bit of a pain in the backside but it would do it

DCTM_Guru

When building the sorting algorithm, you should use i_antecendent_id. This will give you the ID of the parent/previous version (eg 9.0) from the current version (eg 10.0).

Thanks for jumping in and helping, guys!

The problem isn't so much the order of the return values - I get the collation sequence thing. The real problem is the fact that the latest version doesn't show up on the same row, so I don't know what the current version is. Why does it show "9.0,CURRENT" when there are 9 versions, but when I get to version 10, I get "CURRENT" as one return row, and "10.0" as another? This leads to double rows in my front-end when I display the files. I guess I'll have to write the sorting algorithm that goes through all the returned rows and put that back together (and delete the extra row).

Thanks!

Bret

DCTM_Guru

Try this:

DCTM_Guru

Try this:

Thanks, Johnny, but I still get the same results:

config.sys CURRENT

config.sys 9.0

config.sys 8.0

config.sys 7.0

config.sys 6.0

config.sys 5.0

config.sys 4.0

config.sys 3.0

config.sys 2.0

config.sys 10.0

Rgds,

Bret

liaojiyong

hi,

try try the following DQL:

SELECT r_object_id,object_name,r_version_label, r_modifier, r_modify_date,r_object_id,r_object_type,r_lock_owner,owner_name,r_link_cnt,r_is_virtual_doc,r_content_size,a_content_type,i_is_reference,r_assembled_from_id,r_has_frzn_assembly,a_compound_architecture,i_is_replica,r_policy_id,wind_desc, my_class, my_group, my_type FROM my_repository (ALL) WHERE (a_is_hidden = FALSE) and FOLDER('/Projects/888812345',DESCEND) order by my_class asc, object_name asc, r_version_label desc ENABLE(NOFTDQL)

It's definitely the same exact document:

config.sys CURRENT 09008dc780017dd4

config.sys 9.0 09008dc780017dd2

config.sys 8.0 09008dc780017dca

config.sys 7.0 09008dc780017dc8

config.sys 6.0 09008dc780017dc6

config.sys 5.0 09008dc780017dc4

config.sys 4.0 09008dc780017dc2

config.sys 3.0 09008dc780017dc0

config.sys 2.0 09008dc780017dbe

config.sys 10.0 09008dc780017dd4

Note that the first item (CURRENT) and the 10th version are identical Object IDs. I could use this in my algorithm as a way to find the CURRENT version and remove the extra line, but *why should I have to*? This seems like a bug...

Rgds,

Bret

If I remember, you need to also add r_object_id to the order clause. It's all in the DQL documentation

If you do enable all_rows you get a return for every database entry you got. If you don't use it DQL aggregrates the results. The response is correct.

which response ?

The response from documentum.

I need to focus on the coming migration weekend on not on support fora

Jorgen, Francois, Liao - thanks for your time and effort. Respectfully, though, I disagree that the behavior is correct. If I run the *exact same* DQL when there are 1-9 versions, the CURRENT version shows up with the version number , as in:

9.0,CURRENT

8.0

...

1.0

However, when the version hits 10.0 (or 1.10), the *exact same* DQL returns results like this:

CURRENT

9.0

8.0

...

10.0

CURRENT

1.09

1.08

...

1.10

1.01

Also, we've discovered that the object ID is identical for the CURRENT and the last version, which would lead me to think that DM actually stored 2 rows for the same object when there are 10 versions, but stores only 1 row when there are 1-9 versions.

I'll just run my DQL, get my collection, then process the collection to remove the extra row and put it's numeric version into the row that contains the CURRENT label.

Rgds,

Bret

It does indeed store 2 rows.

Don't forget that r_version_label is a repeating attribute meaning that in the RDBMS, there is 1 row per label for the same object ID. In this case, your current version is 10.00 therefore, there is a row for 10.0 and a row for CURRENT. Works as designed at least for that. For the problem that it appears only when reaching 10, I'm kind of surprised. Can't test it as I'm not in front of a machine that can connect to Dctm but will when I'll have a minute (yeah, right, probably in a couple of hundred years )

I just tried

select r_version_label
from dm_document (all) where r_object_id = 'xxxx'

For a document where there is 1 version it shows CURRENT and 1.0 seperately

For a document where there are 603 version it shows CURRENT and 1.0 seperately

Thanks for taking time to test it for me, Jorgen. Odd that we get different results. Are you using all the same DQL hints I am (i.e. (ALL), FOLDER, etc.)? Here's my query:

SELECT object_name,r_version_label, r_modifier,
r_modify_date,r_object_id,r_object_type,r_lock_owner,owner_name,r_link_cnt,r_is_virtual_doc,r_content_size,a_content_type,i_is_reference,

r_assembled_from_id,r_has_frzn_assembly,a_compound_architecture,i_is_replica,r_policy_id,wind_desc,

my_class, my_group, my_type FROM my_repository
(ALL) WHERE (a_is_hidden = FALSE) and
FOLDER('/Projects/888812345',DESCEND) order by my_class asc,
object_name asc, r_version_label desc ENABLE(ROW_BASED)

I'm on 6.5SP1, if that matters. I'll just have to work around it.

Thanks again,

Bret

Bret,

I saw I made a typo in my previous post. It should be 1.603. So no major version but a minor version.

I did try the all statement but not yet the folder statement.

I tested this on 5.3 SP5. I will try to test this on 6.5 SP2 next week if you still need it.

Bret, can you try the following query instead ?

SELECT r_object_id,object_name,r_version_label, r_modifier,
r_modify_date,r_object_type,r_lock_owner,owner_name,r_link_cnt,r_is_virtual_doc,r_content_size,a_content_type,i_is_reference,

r_assembled_from_id,r_has_frzn_assembly,a_compound_architecture,i_is_replica,r_policy_id,wind_desc,

Well, I had to move the last "r_object_id" inside the ENABLE(ROW_BASED) b/c your way threw errors. I wound up with:

.....r_version_label desc, r_object_id ENABLE(ROW_BASED)

I got the same results:

CURRENT

9.0

8.0

...

2.0

10.0

Thanks, though!

Bret

I didn't test it, that's why.

Can you try a simple DQL statement like

select r_object_id,r_version_label from MYTYPE order by r_object_id

if correct (which it should be), then you can build up on it to find out when and where your problem occurs

A-HA! It breaks when I add my "order by" criteria. I built up the query as you suggested and it broke when I added some of my order bys. Thanks very much for sticking this out with me and helping!

Thanks very much everyone, and especially Francois!

Rgds,

Bret