Weird very large numbers in t_objectconstraint.Weight column

[Geert Bellekens]

When experimenting with project transfers, we stumbled upon an issue.
Some of the values stored in the t_objectconstraint.Weight column were too large for the target database.

No upon doing a query, I found that some of these values are indeed ridicilously large. (e.g. 4E+56 and 2E+50, and so on)
When looking in the GUI I don't even see a field that exposes this weight property, so I'm a bit puzzled as how these values got there in the first place.

Does anyone have a similar issue; and possibly a clue on what is going on here?

I can of course set them all to 0 with a simple update query, but I'm afraid they will come back if I don't know where they came from originally.

Geert

[Geert Bellekens]

I found out the weight field is used to store the order of the constraints. If you move them up/down, the weight value gets changed.

I've experimented a bit, but I can't make it misbehave; but it might have been a bug in an earlier version that made those weird figures appear.

Geert

[qwerty]

Will the consitency check repair them?

q.

[Geert Bellekens]

Will the consitency check repair them?

q.

No, I run those regularly, and they haven't touched the weight values.

Geert

[qwerty]

Well, at least one additional info. The current statement about weight in my Inside is "does not seem to be mapped in the GUI".

q.

[Geert Bellekens]

Well, at least one additional info. The current statement about weight in my Inside is "does not seem to be mapped in the GUI".

q.

Yeah, you could change that into "is named wrong and should really be named pos to be consistent with t_attribute etc..."

Geert

[qwerty]

You can bet on that xD

q.

P.S. When you issue a query the Weight actually is shown as a Real number. The example model has a few with weight 1.00 but most being 0.00

[Geert Bellekens]

You can bet on that xD

q.

P.S. When you issue a query the Weight actually is shown as a Real number. The example model has a few with weight 1.00 but most being 0.00

Ah, I can now think of a scenario where that might have gone wrong.

- Get the weight value as string "1.00"
- Try to store the same value as Real, messing up the decimal point/comma notation, and end up storing the value 100 instead.
- Get the weight value as string "100.00"
- Try to store the same value as Real, messing up the decimal point/comma notation, and end up storing the value 10000 instead.
- Rinse and repeat

And that indeed checks out with the actual values found. Most of them are round numbers like 5000000000 or 2000000

Geert

[qwerty]

Yep. I always imagine the DB design troupe of Sparx as a horde of chimps hacking on keyboards. But more likely is: there's just nobody and the trainee is responsible. Who knows. But you can see: it's sick.

I have just published the update...

q.