XPO–11.2 Sneak Peek - Auto-generated Int64 keys

28 July 2011

We are not far from 11.1 and I presume that you will be surprised to see 11.2 sneak peeks at this timeSmile

There is not actually not much to say here, because the subject says it all. Starting from version 11.2 you can define a Int64 (long) key property in your class and mark it with the KeyAttribute, whose AutoGenerate parameter will be set to True:

  1: [NonPersistent, MemberDesignTimeVisibility(false)]
  2: public abstract class XPObjectWithInt64Key : XPCustomObject {
  3:     ...
  4:     Int64 _oid = -1;
  5:     [Persistent("OID"), Key(AutoGenerate = true)]
  6:     public Int64 Oid {
  7:         get { return _oid; }
  8:         set {
  9:             Int64 oldValue = Oid;
 10:             if (oldValue == value) return;
 11:             _oid = value;
 12:             OnChanged("Oid", oldValue, value);
 13:         }
 14:     }
 15:     ...
 16: }
 17: public class TestPerson : XPObjectWithInt64Key {
 18:     public TestPerson(Session session)
 19:         : base(session) { }
 20:     private string firstName;
 21:     public string FirstName {
 22:         get { return firstName; }
 23:         set { SetPropertyValue("FirstName", ref firstName, value); }
 24:     }
 25:     private string lastName;
 26:     public string LastName {
 27:         get { return lastName; }
 28:         set { SetPropertyValue("LastName", ref lastName, value); }
 29:     }
 30: }

Interested readers will notice that for my base persistent class I grabbed the source code from the standard XPObject class and then just changed its key type from Int32 to Int64.

Well, if you now create and save a new object, a key will be automatically generated for it:


I hope you like this small addition to XPO, because it provides you with more flexibility (previously auto generation was supported only for Int32 and Guid keys).

Please let us know your thoughts on this.

Happy XPOingWinking smile

18 comment(s)
Mark Krasnohorsky

Excellent! It is about time. I can finally take out some of those hacks I have in place due to this current limitation.

28 July, 2011
Robert Kapuściński

nice work. We need this

28 July, 2011
Johnny K

we would like to use and vb.net samples plz!

also are int32 allready run out? and int64 is so important?

i dont know, maybe because my records are not in the billions....

28 July, 2011
Marc Greiner (DevExpress MVP)


By default, XPO uses an « int » for the object key.

The C# « int » is what got called « Long » in VB.

If you use such a type as a key for your objects, you can have up to 2 billion records in a table. This is quite a lot, enough for most uses.

Some XPO users asked for bigint keys (64 bits), simply because they have object lists with more than 2 billion records and they don't want to use GUIDs, which is very understandable (GUIDs have several drawbacks).

28 July, 2011
James Zhong


28 July, 2011
Arjan van Dijk

For some scenarios it could be usefull especially if you've billions of records like in telecom. Also, in legacy sql databases there are sometimes identity-gaps so the identy values jumping to very big numbers. In these cases (maybe you must get rid of those "gaps" first) the bigints are a (temporary?) solution.

29 July, 2011
Przemyslaw Wlodarczak


29 July, 2011
Felipe R Machado

I was one of those developers that cried out and loud for this. Our application works with auto-increment fields gathering hundreds of thousands of records each day and we needed a clustered index on the Oid because we needed to get to it as fast as possible given the ID. That was unfeasible using GUIDS because a clustered index in a GUID column will rebuild the index pages all the time since the new record can't be appended at the end because GUIDS are inherently not sortable (which is very stupid, if they'd put the time information at the beginning it would probably work for most situations...). An int32 key field wouldn't work too, because 2 billion records is not enough to cope with all the data through the lifetime of the project...

That's why this simple change is enough to warrant an upgrade!

1 August, 2011
Dennis (DevExpress Support)

@Felipe and others, we are happy to hear that you liked this feature!

3 August, 2011
Sebastian Kiš2

This is great!

Only one more thing is missing in XPO -> using NUMERIC instead of money for decimal (SQL Server)

I often have values that are more precise than 4 decimal places (like 6 or even 9 decimals) and then manually hack data layer to fit it into money :(

13 August, 2011

I agree for an int64 OID.

in persistent Data tables , when objects are inceasedly created and deleted, OID grows . What happens when the max value is attained ?

So, yes for an int64 auto-incremented index

14 August, 2011
Manfred Waldmeyer


How can int64 OID from different source databases be merged?

Our mobile/stationary CRM Solution "oPenCRM 2011", that we are working on, uses offline SQLite DBs on  mobile devices (up to 250 tablet PCs e.g.) and MS SQL Server on stationary PC workstations.

The users can create new records and records referencing these records (eg. order header - details) on their mobile devices and sync their mobile db with the server db. Stationary users can do the same on the server based data.

We currently use guids despite the known indexing problems. Therefore it would be nice if the the autogenerate process would allow using a set of distinct mask MSBs for each database.These bits are ored in the upper part of the OIDs and the incremental bits in the LSB part.

Would that be a possible feature?

15 August, 2011
Arnold King

Thanks! It's needed!

15 September, 2011

I am afraid the Auto-generated Int64 keys do not work with PostgreSQL (we are using the Ngpgsql ODBC provider v2.0.11.92 + PostgreSQL 9.1.2).

The table column for the auto-generated primary key of type int64 in the base class is incorrectly generated as integer, although in all inherited classes the table column for this field is correctly generated as bigint.

Nevertheless, even though the above sample does not work with PostgreSQL I must point out that the auto-generated primary key of type int64 is correctly generated as bigint in Microsoft SQL Server as advertised (i.e. the above sample code works flawlessly with MS SQL, just not with PostgreSQL).

18 December, 2011
ari laksono

good, its time to big data...

good bless DXv2

28 December, 2011
vinod pandey


20 June, 2014
vinod pandey


20 June, 2014
vinod pandey


20 June, 2014

Please login or register to post comments.