copying OOB date field to a custom date field

[Demo24]

Hello,

I have a requirement to edit system field "sys_created_on" but since they are OOB system fields and best practice is not to edit these, I decided to create a date/time field "u_creation_date" so that this creation date field can be editable by certain role bearing users and this new field can be used for the reporting purpose.

but since at the start the field is empty, I want the value to be copied from OOB "sys_created_on" field and will edit it later if needed. To copy this I tried below fix script in my PDI first:

var gr = new GlideRecord('u_test_table');
gr.query();
while(gr.next())
   {
if(gr.u_creation_date == ''){
   gr.u_creation_date = gr.getValue('sys_created_on');
   gr.setWorkflow(false);
   gr.autoSysFields(false);
   gr.update();
}
}

now, the issues are:

1. The field is not copying exact value as that in OOB created field for few records. How do I copy exact value

2. I should run this fix script on production instance where there will be around 50000 records, will that be okay or will there be any data loss if I do it on production. Is this not recommended? if yes then is there any alternate solution for this?

Please help me with this!

[Charles Louis1 · Accepted solution]

Hi

Can you try this 

var gr = new GlideRecord('u_test_table');

gr.query();

while(gr.next()){

if(gr.u_creation_date == '')

{

var gdt=new GlideDateTime(gr.sys_created_on);

gr.u_creation_date = gdt;

gr.setWorkflow(false);

gr.autoSysFields(false);

gr.update();

}

} 

Please Mark it as correct if its helpful.

[Demo24]

Hi @Mervin 

Thanks a lot, issue got resolved.

I wanted to check with you about the second point in my question, does this method of using fix script in production to copy date value go against servicenow best practices? or is it okay to have this?

[Charles Louis1]

you can use fix script no issue in that 

Please Mark it as correct if its helpful.

[Anil Lande]

Hi,

The purpose of fix scripts are to make data corrections or update/create bulk records.

As long as your script is working fine and only updating required fields you can run it in production.

• Before doing that make sure it is adding some business value to your table and process.
• The solution is accepted and approved by required stakeholders.
• As you are adding custom field make sure you have required subscriptions to make such customizations.
• Run these scripts on sub production instances and make sure there are no side effects.

Thanks,

Anil Lande