CA Service Management

Hi Team

is there any limitation in servicedesk to create custom tables n columns? currently we have 6 custom tables and around 60 custom columns created in different tables in  chg, cr etc. 

We have still many customization request from different teams which need to create more columns n tables. So please confirm if there is any limitation?

Many thanks 

Hi Aamir,

Please have a look at this KB article that may help to answer your query somewhat:

Is there any limitation for the number of custom c - CA Knowledge 

===

Kind Regards,

Brian

As far as I am aware the limitation is based on the DB.

For oracle it seems: 4096 columns per table and and  65,535 Bytes row size.

for MS SQL server the limits seem to be lower, but I did not find reliable information at a first look.

The problem mentioned in the doc referred Brian, is a bug in spel, from my point of view, meaning this problem can be , and should be fixed by a change in the "chg::make_from_template" method.

I assume , that with the numbers you mentioned, you are not hitting any problem.

Regards

..........Michael

Though there is no official doc how many attributes you can add to an object, I don't recommend adding too many

to ticket tables...

at some point you will hit ilimit error if you keep adding...

if you have so many why not consider adding a new table and link the table in the ticket object?

I think Chi has the best answer.

The knowledge document is correct:

"This limitation is caused by the SPEL code within ServiceDesk. If the columns increase beyond the threshold, there will be negative impact on ServiceDesk performance."

I can't recall what the limit is, but the Call_Req table is an example of one which is pretty close to the limit already, and then you have another 60 columns.

It would be better to shift the load off this table onto other tables where possible.

Thanks, Kyle_R.

Its not recommended to overload an object with too many fields as it may create impact on performance and interestingly deleting a field from object layer/db layer is too complex and error prone. Hence be wise before adding it. The easy solution is to create new tables with SREL/LREL relation with the actual table.

Thanks

ArunavaS

Some thoughts and facts:

The knowledge doc referenced by Brian is showing a problem when creating tickets from a template.

The underlaying coding in this situation creates a new ticket ,

initialize it (i.e. creating a new ticket number),

and then loops through all known attributes of the template

and copying the template attribute value to the new ticket attribute value.

This loop hits a certain "maximum code step limit" called ilimit, and therefor fails at a certain number of attributes.

This ilimit stuff normally takes care about, that a loop in the program code is not iterating forever.

Again, there is no hardcoded limit, no check of a maximum number of columns anywhere I am aware.

That might be the reason nobody is able to say what is the exact column limit.

There are certain other areas, where the coding loops through lists of whatever data, and ran into the ilimit problem as well.

Here the coding was fixed, so, that these loops were not hitting this very internal limit.

This is the reason I was saying, this is a bug and can be fixed.

Anyway, there might be other limits somewhere in the code. For example hardcoded array sizes etc.

Additionally, I'd like to remark, that the idea of moving attributes from a ticket table to another separate table might impact, what you are trying to achieve, and therfore not the appropriate solution.

Attributes of a ticket are part of the ticket itself and so, their values are unique to a specific ticket.

If you create a another table and only creating an SREL attribute in the ticket table referencing a record in the new table,

these attributes are not part of the ticket anymore, but now belonging to the referenced table record

This is comparable to any other SREL attribute, like affected_contact, ci, etc.

Of course this has some consequences.

a "create from template" will just copy the reference of the new table record, to the new ticket.

a "copy" will do just the same.

Now many tickets might have the same attribute values, because they are referencing the same record.

Another disadvantage would be, you would not be able to edit the values of the referenced record when you edit the ticket. For example, you are not able to edit the contact attributes of the affected user when editing the ticket.

Some of these consequences might be solvable, by implementing additional application logic. But of course all these additional solutions will lead to custom code, which is officially not supported at all.

I fully agree that one should not add attributes carelessly, due to several reasons

Nevertheless, if there is a real business need, you might not have any alternative.

I know systems that are highly customized with hundreds of new tables and fields, but 60 additional attributes in a ticket table is very unusual. I am wondering if these 60 attributes are all relevant to the ticket process. Maybe considering the use of properties or an additional ticket entity, like issues.

Regards

.....Michael