Hello,

i'm trying to build Selfservice DatabaseFirst code in LLBLGEN 4.2 on a table with a Unsigned BigInt as ID

LLBLGEN maps this field to a Decimal. When trying to map it to a UInt64 it needs a TypeConverter.

Why should i use a type converter to convert between: MySQL 64 bit unsigned integer and a .Net 64 Bit Unsigned Integer.

It's the same.

Also tried LLBLGEN 5.0 if this was fixed but has the same problem.

Greets

Remon

That's the type returned by the data provider.

Please check the mappings here. https://www.devart.com/dotconnect/mysql/docs/datatypemapping.html

Could you please try using a typeConverter?

Thanx,

will forward my question to dataprovider support forum.

OK it's been a while but got the Typeconverter working. It can only return a decimal.

If i set the field type to ulong the Sequence LAST_INSERT_ID() is cleared in the designer.

Why is this i can use a type converter to converte from decimal to ulong to use in code

Just installed LLBLGEN Pro 4.2 May 2016. This is the latetest 4.2 i can find.

Still no luck i can't use ulong in combination with Sequence -> LAST_INSERT_ID

I Want to use a type converter to converte between a bigint and ulong

When using the Typeconverter all goed well except the part when a new entity is created it does not have an id.

I think this is the part where the LAST_INSERT_ID should kick in but because i can't select is it does always return 0 as id.

rlucassen wrote:

Just installed LLBLGEN Pro 4.2 May 2016. This is the latetest 4.2 i can find.

Still no luck i can't use ulong in combination with Sequence -> LAST_INSERT_ID

I Want to use a type converter to converte between a bigint and ulong

When using the Typeconverter all goed well except the part when a new entity is created it does not have an id.

I think this is the part where the LAST_INSERT_ID should kick in but because i can't select is it does always return 0 as id.

true, I can reproduce this. As soon as the types don't match or when a type converter is needed, the sequence is no longer settable. If both types (entity field type and db field type) are equal, be it ulong, decimal whatever, the sequence is settable.

We'll look into this.

Btw, you don't need to specify an unsigned bigint to use an unsigned bigint sequence in MySQL. No-one is going to insert (2^64)-1 rows in a table before the end of time. 2^64 is 18446744073709551616. If you insert every 1ms 1 row, it will take 213503982335 days before you run out of keys. Which is 584942417 years.

If you use a signed bigint, it will be a ulong in mysqldirect and will map to an ulong, no type converter needed.

Using an unsigned bigint as PK is seriously overkill in this and the requirement of a typeconverter especially makes it more complex than needed.

Bug in designer. It checks whether a type is numeric to receive a sequence. 'Uint64' isn't part of the set of types it checks for. Interesting that this has been gone undetected for so long! Working on fix.

Fixed. Please download latest v4.2 build from the website.

v5.0.7 hotfix will be uploaded shortly.

Otis wrote:

rlucassen wrote:

Just installed LLBLGEN Pro 4.2 May 2016. This is the latetest 4.2 i can find.

Still no luck i can't use ulong in combination with Sequence -> LAST_INSERT_ID

I Want to use a type converter to converte between a bigint and ulong

When using the Typeconverter all goed well except the part when a new entity is created it does not have an id.

I think this is the part where the LAST_INSERT_ID should kick in but because i can't select is it does always return 0 as id.

true, I can reproduce this. As soon as the types don't match or when a type converter is needed, the sequence is no longer settable. If both types (entity field type and db field type) are equal, be it ulong, decimal whatever, the sequence is settable.

We'll look into this.

Btw, you don't need to specify an unsigned bigint to use an unsigned bigint sequence in MySQL. No-one is going to insert (2^64)-1 rows in a table before the end of time. 2^64 is 18446744073709551616. If you insert every 1ms 1 row, it will take 213503982335 days before you run out of keys. Which is 584942417 years.

If you use a signed bigint, it will be a ulong in mysqldirect and will map to an ulong, no type converter needed.

Using an unsigned bigint as PK is seriously overkill in this and the requirement of a typeconverter especially makes it more complex than needed.

when using a signed bigint it mapes to a long by default. Mapping a signed bigint to a unsigned long wouldn't make sense what to do with negative values.

A overflow can occur in de database. The signed.max is smaller than a unsigned.max.

We never dit a comparison between signed bigint and unsigned bigint. And indeed is a bit overkill so i think we'll go with the signed long/signed bigint without a type converter.

Thanx for the advice and the fast hotfix