adding row to udProjectSmall through ejscript


One of our customer needs a LOT of udef-fields and since SuperOffice has restrictions to how many e.g. DateTime-fields you can have I started putting new fields in an extraTable in Service instead. For this i have create a custom screen that shows all the udefs from project and all the udefs from my custom table, to make it easier for them to maintain.

I create a map of all the udef-values that are supposed to go to the udef-fields on the project and save it like this: 

NSProjectAgent pAgent;
  NSProjectEntity pEntity = pAgent.GetProjectEntity(projectId.toInteger());
  pEntity = pAgent.SaveProjectEntity(pEntity);

This works well for existing projects but new ones dont have a row in udprojectSmall.. This makes the code fail, as it fails to 'update the row', and im wondering why it doesnt create a new row if there is none.. 

I could possibly fix this with a trigger in the database but i want this to be 'online-friendly' to have a working example for the future. 

Is there any way to create this row in udprojectSmall with some 'standard stuff'? I guess i can just insert it with a searchengine but that is my last resort.. 


RE: adding row to udProjectSmall through ejscript

Make the client do it. In admin, each user defined field may have a default value:

Adding a value here will force a new row in the corresponding udxxx-table each time a new project is created.

Av: Margrethe Romnes 23. mai 2019

RE: adding row to udProjectSmall through ejscript

Ah, that was a good way of solving it, thanks! :)

Btw it looks like i was wrong to begin with, I have tested this some more and it looks like it actually creates a new row if it doesn't find one.. weird that it failed for me yesterday, must have been a typo and/or user-error.. 


Av: Eivind Johan Fasting 23. mai 2019

RE: adding row to udProjectSmall through ejscript

Hi Eivind,

At least before, it worked that way, that when creating a new entity, a record in the corresponding entity-udef-table is only created automatically if there are udef-fields with default values set. Otherwise a corresponding record in the entity-udef-table will only be created the first time you are writing a udef-value to the main entity.

So, per default, you cannot assume that there actually is a corresponding entity-udef-record. At least not if it isn't part of the solution that you are setting a default value in one of the udef-fields, as Margrethe suggests (which is a good way to ensure that).

So, architecturally, that could be good to keep in mind. :)


Av: Marcus Svenningsson 27. mai 2019