While we're moving some applications to new environments we face some problems with Static Entities.

The Id's of the Static Entities are autonumbered integers.  In some cases the order of the Id's in the new environment is no longer the same as the order of the Id's in the original environment.  

Nothing wrong with this since they were defined as autonumbered.

The foreign keys of the entities with a relationshiop with these static entities however, are not changed (that's the result of a database copy).  

Anyone knows how to rearrange the order of the static entities ?

I'm looking for a systems table that holds the information that Entities.Status.CheckedOut corresponds to Id=4 in the original installation and Entities.Status.CheckedOut corresponds to Id=2 in the new installation.

It would be nicer to change all the foreign keys.  But I think the price is too high for that conceptual beautyness (extra work, error prone, downtime, ...).

Found it : ossys_Entity_Record .
Case closed.



I think using IDs not auto number would solve this problem.

Not being possible, and assuming the problem raises because you are moving "data", you may want to use a tool able to recognize this and deal with it (I know at least one commercial solution).

In the worst case, I think you would have to prepare lookup tables in order to run a script to fix the IDs on the FKs.



Personally I don't like to change things in the metadata. Too risk if you don't know very well the meta model...

Hi Bob,

This is why it's good practice to not use autonumbers for Static Entities. It's a shame the Platform even allows it. That said, if you copy the entire database, the order shouldn't change, as the Static Entities themselves are also copied (unless of course it's an external database or a different catalogue).

As for the meta model, there's the Entity_Record System Entity that contains the records of Static Entities. However, as with all meta model System Entities, be very, very careful what you update (and of course refresh and republish every Consumer after changing it).

Kilian expressed my concerns much better. I still would go for a fix in the data, but I understand the urge for an "easy" fix...

Another option may be to set Auto Number to False, manually add the right Ids and republish. That should keep the tables identical, and the Ids the same across installations.

Thanks for the comments.  

Setting Autonum = No is no longer an option.  So I have to go for the risky way (entity_record) or the lonely way (foreign keys).  I looked at the entity_record table and...  I think I'll go for the foreign keys.  :-)  

If setting the autonumber to off isn't possible, you could try removing the Id altogether, and re-adding it with the same name.

The experience I had with ID is that once it is published, it is not possible to change it or remove it.

Well, you are right, conceptually :). I can remove and recreate it, but then I get an error while publishing. So forget that idea :).