Skip to main content

Hello Team,

In Astea Alliance 14 - UAT Environment - We made a customization on Service Order History Module (c_order_line). We added a field called cst_ref → referring to the ref.no field in Service Order Module (order_line). Later we found that there is already a reference to ref.no field in SV history. Hence, we don’t need this customization, so deleted it.

Unfortunately, the new field cst_ref was not removed from c_order_line table and was causing issues in invoicing. As now order_line and c_order_line is not idnetical in terms of columns.

 

So, we reached out to IFS via support portal, and they asked us to drop the column using alter query and we did.

Now the table is back to normal, but still the application cannot open anything related to SV history module. In event log we found that the application uses SELECT query in which it explicitly asks for cst_ref column (which is now removed), hence getting error.
How to make application not use this column anymore?
Need suggestion on this.

Hi,

When you create a customization, it creates a custom DAL that is located in the AsteaShare filestoragepath for the profile in the customizations DAL folder there.  It sounds to me like this was not updated for some reason.

As there are Customizer customizations for the module, the DAL from the filestoragepath is the one picked up by the application as priority versus the standard layer or customization layer (ASTC/ASTL).

 

Perhaps, you can try this… with the field removed from service order, export the customizations with the Export function (you can specify specific modules to export) for just the service order and service order history.  Then using customizer manager, delete the customizations in total.  The export is a backup of whatever was in the public (not dev, not QA).  You can use this export to load it back into the system from the Customizer.

See if this helps…

 

Hi Phil,

Thanks for your suggestion.

I just exported the customization from customization manager.

But before proceeding to delete the existing customizations, I unzipped the .gz file and opened it in a notepad, just to be sure.

There I found this.

“
if not exists (select 'x' from sysobjects,syscolumns  where 
sysobjects.type='U'  and sysobjects.id = syscolumns.id  and
sysobjects.name ='c_order_line' and syscolumns.name = 'cst_ref')
alter table c_order_line add cst_ref varchar (200) NULL
”

looks like it will again create the cst_ref column if I import back.

 

The situation is

  1. UI (has no cst_ref)
  2. customization manager (shows no record of this, as deleted already)
  3. Data dictionary, DAL and other app files (has cst_ref)
  4. DB (has no cst_ref as we dropped it)

Ok, too bad… and good catch to check once exported.

Since we can’t do this via the UI any longer, it looks like the export file will need to be modified to take out the references to the cst_ref in the files.

I suggest logging a ticket with support, attach your export .gz file and provide the details what you are trying to do (meaning your description of the problem and current situation).  Support should review this file and hopefully fix it to provide back to you.

This is not something I think we can address via Community.

Ok Thanks for your time and replies.
Much appreciated.

Will reach out to support team.

Reply


Terms & ConditionsCookie settings