Home » discuss » Public forums » Developing for iMIS

Saving CContact object is very slow.

Posted February 22nd, 2010 by Brad Engels
| | | | |

I have been having an issue with slowness involved with calling the Save() method on a CContact object using iBO for .NET.  When saving a CContact object, it consistantly takes 8-12 seconds to complete. We have a rather large database (over 600,000 records in the Name table), and it seems that the issue lies within the asi_Name_Insert_Update trigger, more specifically the asi_FixDuplicateIndividualRows stored procedure that runs when the MEMBER_TYPE, COMPANY_RECORD, or MEMBER_RECORD columns are edited.

If I use SQL to edit a field on the Name table, it takes about 2 seconds compared to the 8-12 iBO takes. It seems that when I run contact.Save(), the method is updating every field in the Name table rather that just the ones that had been edited, which is triggering asi_FixDuplicateIndividualRows to run. Is there any way to resolve this other than using SQL commands in place of CContact? Can I comment out the asi_FixDuplicateIndividualRows in the Name trigger (since we do not use company/institution records)?

I am using the latest iBOs (from 15.1.2).

Thanks

‹ How to obtain particular versions of a an Asi assemblyDebugging desktop connection issues ›
login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What version is the

On February 22nd, 2010 Eric Means says:

What version is the iMIS database? The trigger is independent of the iBO version, so just updating iBO won't fix any trigger-related issues.

Eric Means
System Architect, ASI

login or register to post comments

The database is 15.1.2.5397

On February 22nd, 2010 Brad Engels says:

The database is 15.1.2.5397

login or register to post comments

One option to try would be

On February 22nd, 2010 Paul Bradshaw says:

One option to try would be to disable the trigger, perform all your updates, then re-enable the trigger and then call dbo.asi_SyncNetContacts.  That procedure call will take a while to run on a database as large as yours, for sure, but at least you won't burn that time on each update, but only at the end.

I don't recommend just commenting out the call to that stored procedure from the trigger, simply because OTHER updates might happen that modify those fields, and then you'd end up with inconsistent data in the database that could cause issues down the road.

If dbo.asi_SyncNetContacts still takes too long to run for you in your case (it very well might), you can try modifying one line in this stored procedure to see if it helps... change the line:

SET COMPANY_RECORD = COMPANY_RECORD

to

SET FIRST_NAME = FIRST_NAME

Since updating FIRST_NAME will cause the trigger to run, but won't invoke FixDuplciateIndividualRows.

 

 

 

login or register to post comments