Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Avid Listener
Posts: 17
Registered: ‎03-09-2010

Integrity Checker Tests

Hi,

When creating a new Integrity Checker test to update a table it seems to automatically update the MODIFYDATE of that table, even though it is not in the UPDATE statement for the test.  Is there any way of stopping that from happening.  We have sometimes to fix the data in one field in all records in the table due to a bug but don't want to change the modifydate as there is some other functionality that relies on this date to include/exclude records in an automated export - this should be based on user modification.

Thanks.

Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: Integrity Checker Tests

It's the SalesLogix provider that is doing it automatically. IF an Update or Insert (be it SQL statements or an ADO recordset) does to specify a value for:

   A - CREATEDATE

   B - CREATEUSER

   C - MODIFYDATE

   D - MODIFYUSER

Then the provider will do it automatically.

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Integrity Checker Tests

While I absolutely agree that *any* update should be noted via *modify* fields, there clearly should be a distinction made between system leveraged mass updates like Integrity Checker, Exec SQL and Replace Data typically done by administrators and manual updates made by users. The reason that kicked off this thread is a perfect example of why and there are others like simply confirming who made the last manual update and when. While I know there are much bigger fish to fry and perhaps little support for this suggestion, it would be nice if each table had 2 additional fields, smodifydate and smodifyuser, to document system generated updates without overwriting user generated updates.

Thanks,
Larry Esposito
Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: Integrity Checker Tests

Not disagreeing.. however, it took years (.. and years) to get all the table in SLX to have the 4 basic fields. For the longest time, SalesLogix felt that we did not need them on all the tables (ex: "internal tables w/metadata"). They finally saw the light. Having the provider do certain functions for us was also a great stride forward.

 

As far as anything changing (now).. I'd bet 100% no. 

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Bronze Super Contributor
Posts: 349
Registered: ‎03-24-2009

Re: Integrity Checker Tests

Untested idea - what if you include ModifyDate=ModifyDate, ModifyUser=ModifyUser in your SQL update? I would test this in your development system first of course. Maybe including updates to the columns will trigger the provider to leave them alone.
Timmus Agersea
Black Moth CRM
Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: Integrity Checker Tests

Sounds like it should work. Something that can be easily tested.
--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Avid Listener
Posts: 17
Registered: ‎03-09-2010

Re: Integrity Checker Tests

Thanks guys.