arsdoc update - Revision history

Jderrick: Formatting tweak for CMOD arsdoc update article.

2020-11-12T11:56:59Z

Formatting tweak for CMOD arsdoc update article.

← Older revision		Revision as of 11:56, 12 November 2020
Line 55:		Line 55:

	== Changing the data with arsdoc update ==		== Changing the data with arsdoc update ==
	[[File:Attention.png\|~~70px~~\|left]] WARNING: There is no 'undo' command for <code>arsdoc update</code>. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running <code>arsdoc update</code>, as well as exporting unmodified copies of your tables to revert changes with relative ease. Contact your local DBA for assistance in creating backups of the OnDemand management tables (starting with 'ARS'), and Application Group tables that will be modifed, so they can be restored without requiring a database outage for a full restore.		[[File:Attention.png\|50px\|left]] WARNING: There is no 'undo' command for <code>arsdoc update</code>. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running <code>arsdoc update</code>, as well as exporting unmodified copies of your tables to revert changes with relative ease. Contact your local DBA for assistance in creating backups of the OnDemand management tables (starting with 'ARS'), and Application Group tables that will be modifed, so they can be restored without requiring a database outage for a full restore.

	Formulating the actual <code>arsdoc update</code> command is tricky, and takes practice to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.		Formulating the actual <code>arsdoc update</code> command is tricky, and takes practice to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.

Jderrick at 11:55, 12 November 2020

2020-11-12T11:55:35Z

← Older revision		Revision as of 11:55, 12 November 2020
Line 4:		Line 4:
	Again, if you are a OnDemand Administrator being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to require IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.		Again, if you are a OnDemand Administrator being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to require IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.

	[[File:Attention.png\|~~70px~~\|left]] WARNING: It is not just possible, but '''extremely easy''' to irrecoverably damage the data in your Content Manager OnDemand server with the <code>arsdoc update</code> command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!		[[File:Attention.png\|50px\|left]] WARNING: It is not just possible, but '''extremely easy''' to irrecoverably damage the data in your Content Manager OnDemand server with the <code>arsdoc update</code> command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect! <br/> <br/>
			If you're interested in learning more about Content Manager OnDemand's arsdoc utility, consider attending the [https://cmod.training/using-cmods-arsdoc-query-get-update/ Free CMOD Webinar on arsdoc offered at CMOD.Training].

	== arsdoc update parameters ==		== arsdoc update parameters ==

Jderrick: arsdoc update re-write, second attempt.

2020-05-12T02:15:52Z

arsdoc update re-write, second attempt.

← Older revision		Revision as of 02:15, 12 May 2020
Line 4:		Line 4:
	Again, if you are a OnDemand Administrator being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to require IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.		Again, if you are a OnDemand Administrator being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to require IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.

	[[File:Attention.png\|~~100px~~\|left]] WARNING: It is not just possible, but '''extremely easy''' to irrecoverably damage the data in your Content Manager OnDemand server with the <code>arsdoc update</code> command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!		[[File:Attention.png\|70px\|left]] WARNING: It is not just possible, but '''extremely easy''' to irrecoverably damage the data in your Content Manager OnDemand server with the <code>arsdoc update</code> command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!

			== arsdoc update parameters ==
			Here's a copy of the online help, which you can access simply by issuing the command <code>arsdoc update</code> with no parameters:

			{\| class="mw-collapsible mw-collapsed wikitable"
			! IBM Content Manager OnDemand arsdoc update parameters
			\|-
			\|
			$ arsdoc update
			ARS6001I Usage: arsdoc update -h hostname [-u <userid>] [-p <passwd>] [-U <user_alias>] [-v] (-F <parmfile> \| ((-i <sql_query> \| -l <holdname> \| -q <namedquery> \| -t <search_str> \| -T <search_str> \| -X <load_id> \| -x <load_id>) [-f <foldername>] [(-g <name> \| -G <name>)] -n field1=value1 [-S <startdate,enddate[,format]>])) [-1 <trace_file>] [-2 <trace_level>]
			Version: 10.5.0.0
			-f <foldername> OnDemand folder (required in parm file)
			-g <name> Application Group Name
			-h <hostname> OnDemand Hostname (command line only)
			-i <sql_query> SQL query string
			-l <holdname> OnDemand hold
			-n <field1=value1> One or more database field names and values
			-p <passwd> OnDemand User Login Password Stash File (command line only)
			-q <namedquery> Public named query
			-t <search_string> Server text search
			-u <userid> OnDemand User Login Name (command line only)
			-v Verbose (command line only)
			-x <load_id> LoadId to use for OnDemand
			-F <parmfile> Requests parameter file (command line only)
			-G <name> Application Group Name
			-S <startdate,enddate[,format]> Segment date range
			-T <search_string> Full text search
			-U <user_alias> User alias that appears in System Log messages
			-X <load_id> LoadId to use for OnDemand
			-1 <trace_file> Trace file (command line only)
			-2 <trace_level> Trace level (command line only)
			Flags in a parameter file must be delimited by brackets EX: [-f foldername]
			\|}
	== Preparing to run arsdoc update ==		== Preparing to run arsdoc update ==
	Before running <code>arsdoc update</code>, you need to complete two steps. First, identify the Folder or Application Group you will be modifying, and understand the structure -- identify the Folder field names, or Application Group field names, plus the type of data and format of dates fields, and make sure that the fields you'll be changing have the 'Updatable' flag checked in the Application Group Configuration.		Before running <code>arsdoc update</code>, you need to complete two steps. First, identify the Folder or Application Group you will be modifying, and understand the structure -- identify the Folder field names, or Application Group field names, plus the type of data and format of dates fields, and make sure that the fields you'll be changing have the 'Updatable' flag checked in the Application Group Configuration.
Line 11:		Line 43:

	== Create the search criteria for arsdoc update ==		== Create the search criteria for arsdoc update ==
	There are two ways to create the criteria that will be used to execute the change. You can perform a search of your new folder, and save the search parameters as a 'Named Query' in the Content Manager OnDemand Windows 'Thick Client', or format your search for <code>arsdoc</code> using the same parameters as [[arsdoc_query]].		There are two ways to create the criteria that will be used to execute the change. You can perform a search of your new folder, and save the search parameters as a 'Named Query' in the Content Manager OnDemand Windows 'Thick Client', or format your search for <code>arsdoc</code> using the same parameters as [[arsdoc_query\|arsdoc query]].

	Insert diagram here - creating a named query		Insert diagram here - creating a named query
Line 19:		Line 51:

	== Double checking the changes with arsdoc query ==		== Double checking the changes with arsdoc query ==
	Before proceeding to the next step, double check the documents you'll be modifying by testing your search criteria with the [[arsdoc_query]] command. When <code>arsdoc query</code> returns ONLY the documents you want to modify, should you perform the <code>arsdoc update</code> command.		Before proceeding to the next step, double check the documents you'll be modifying by testing your search criteria with the [[arsdoc_query\|arsdoc query]] command. When <code>arsdoc query</code> returns ONLY the documents you want to modify, should you perform the <code>arsdoc update</code> command.

	== Changing the data with arsdoc update ==		== Changing the data with arsdoc update ==
	[[File:Attention.png\|~~100px~~\|left]] WARNING: There is no 'undo' command for <code>arsdoc update</code>. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running <code>arsdoc update</code>, as well as exporting unmodified copies of your tables to revert changes with relative ease. Contact your local DBA for assistance in creating backups of the OnDemand management tables (starting with 'ARS'), and Application Group tables that will be modifed, so they can be restored without requiring a database outage for a full restore.		[[File:Attention.png\|70px\|left]] WARNING: There is no 'undo' command for <code>arsdoc update</code>. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running <code>arsdoc update</code>, as well as exporting unmodified copies of your tables to revert changes with relative ease. Contact your local DBA for assistance in creating backups of the OnDemand management tables (starting with 'ARS'), and Application Group tables that will be modifed, so they can be restored without requiring a database outage for a full restore.

	Formulating the actual <code>arsdoc update</code> command is tricky, and takes practice to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.		Formulating the actual <code>arsdoc update</code> command is tricky, and takes practice to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.

Jderrick: Full re-write of arsdoc update article - step 1.

2020-05-12T01:00:03Z

Full re-write of arsdoc update article - step 1.

Jderrick: Added warning icons, multiple small changes.

2017-12-10T19:00:54Z

Added warning icons, multiple small changes.

← Older revision		Revision as of 19:00, 10 December 2017
Line 2:		Line 2:
	In IBM CMOD, the arsdoc update command is used to change index values of data that is already loaded. This may be used to update a status field used for workflow or tracking, but should not be used to update index data used to search for documents, as you could render documents irretrievable.		In IBM CMOD, the arsdoc update command is used to change index values of data that is already loaded. This may be used to update a status field used for workflow or tracking, but should not be used to update index data used to search for documents, as you could render documents irretrievable.

	If you are being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to force IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your ~~archive~~ will not be considered a reliable archive.		If you are being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to force IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.

	WARNING: It is not just possible, but extremely easy to irrecoverably damage the data in your ~~CMOD~~ server with the arsdoc update command. The examples below are meant as a guide only, and you are solely responsible for any damage to your ~~IBM CMOD~~ server. Practice makes perfect.		[[File:Attention.png\|100px\|left]] WARNING: It is not just possible, but extremely easy to irrecoverably damage the data in your Content Manager OnDemand server with the arsdoc update command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!

	== Preparing to run arsdoc update ==		== Preparing to run arsdoc update ==
Line 16:		Line 16:

	=== Date formats when using arsdoc update ===		=== Date formats when using arsdoc update ===
	IBM ~~CMOD~~ date formats are always tricky - it's best to use the date format specified in the folder definition when creating the parameters for your arsdoc update commands. If you write your own SQL, prefix any date fields with "ODDAT." so that the database can attempt to convert the date format for you.		IBM Content Manager OnDemand date formats are always tricky - it's best to use the date format specified in the folder definition when creating the parameters for your arsdoc update commands. If you write your own SQL, prefix any date fields with "ODDAT." so that the database can attempt to convert the date format for you.

	== Double checking the changes with arsdoc query ==		== Double checking the changes with arsdoc query ==
Line 22:		Line 22:

	== Changing the data with arsdoc update ==		== Changing the data with arsdoc update ==
	WARNING: There is no 'undo' command for arsdoc update. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running arsdoc update. If a CMOD database backup isn't reasonable, then have your DBA create a backup of the ~~CMOD~~ management tables (starting with 'ARS', and Application Group tables, so they can be restored without having to resort to a full database outage.		[[File:Attention.png\|100px\|left]] WARNING: There is no 'undo' command for arsdoc update. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running arsdoc update. If an IBM CMOD database backup isn't reasonable, then have your DBA create a backup of the OnDemand management tables (starting with 'ARS'), and Application Group tables, so they can be restored without having to resort to a full database outage.

	Formulating the actual arsdoc update command is tricky, and takes practise to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.		Formulating the actual arsdoc update command is tricky, and takes practise to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.

Jderrick: /* Preparing to run arsdoc update */

2017-12-10T18:50:13Z

Preparing to run arsdoc update

← Older revision		Revision as of 18:50, 10 December 2017
Line 8:		Line 8:
	== Preparing to run arsdoc update ==		== Preparing to run arsdoc update ==
	Before running arsdoc update, you need to complete two steps. First, create a new folder that consists only of the fields you wish to search and update using the arsdoc update command. Second, ensure that you have permissions to access the folder, and permissions to update the fields in the SINGLE Application Group that require changes.		Before running arsdoc update, you need to complete two steps. First, create a new folder that consists only of the fields you wish to search and update using the arsdoc update command. Second, ensure that you have permissions to access the folder, and permissions to update the fields in the SINGLE Application Group that require changes.
	[[File:ArsdocUpdate-EnablingChanges.png\|700px\|~~left~~\|Enabling Index Data Changes for Application Groups & Folders]]		[[File:ArsdocUpdate-EnablingChanges.png\|700px\|center\|Enabling Index Data Changes for Application Groups & Folders]]

	== Create the search criteria for arsdoc update ==		== Create the search criteria for arsdoc update ==

Jderrick: Added File Enabling Index Data Changes for Application Groups & Folders

2017-12-10T18:48:09Z

Added File Enabling Index Data Changes for Application Groups & Folders

← Older revision		Revision as of 18:48, 10 December 2017
Line 8:		Line 8:
	== Preparing to run arsdoc update ==		== Preparing to run arsdoc update ==
	Before running arsdoc update, you need to complete two steps. First, create a new folder that consists only of the fields you wish to search and update using the arsdoc update command. Second, ensure that you have permissions to access the folder, and permissions to update the fields in the SINGLE Application Group that require changes.		Before running arsdoc update, you need to complete two steps. First, create a new folder that consists only of the fields you wish to search and update using the arsdoc update command. Second, ensure that you have permissions to access the folder, and permissions to update the fields in the SINGLE Application Group that require changes.
			[[File:ArsdocUpdate-EnablingChanges.png\|700px\|left\|Enabling Index Data Changes for Application Groups & Folders]]
	~~Insert diagrams here~~ - ~~create folder~~ & ~~assign permissions~~

	== Create the search criteria for arsdoc update ==		== Create the search criteria for arsdoc update ==

Jderrick: Initial Edit of arsdoc update command article.

2017-12-10T15:50:41Z

Initial Edit of arsdoc update command article.

New page

{{TOCright}}
In IBM CMOD, the arsdoc update command is used to change index values of data that is already loaded. This may be used to update a status field used for workflow or tracking, but should not be used to update index data used to search for documents, as you could render documents irretrievable.

If you are being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to force IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your archive will not be considered a reliable archive.

WARNING: It is not just possible, but extremely easy to irrecoverably damage the data in your CMOD server with the arsdoc update command. The examples below are meant as a guide only, and you are solely responsible for any damage to your IBM CMOD server. Practice makes perfect.

== Preparing to run arsdoc update ==
Before running arsdoc update, you need to complete two steps. First, create a new folder that consists only of the fields you wish to search and update using the arsdoc update command. Second, ensure that you have permissions to access the folder, and permissions to update the fields in the SINGLE Application Group that require changes.

Insert diagrams here - create folder & assign permissions

== Create the search criteria for arsdoc update ==
There are two ways to create the criteria that will be used to execute the change. You can perform a search of your new folder, and save the search parameters as a 'named query' in the Content Manager OnDemand Windows 'Thick Client', or manually create an SQL statement that finds the specific documents you're looking to change.

Insert diagram here - creating a named query

=== Date formats when using arsdoc update ===
IBM CMOD date formats are always tricky - it's best to use the date format specified in the folder definition when creating the parameters for your arsdoc update commands. If you write your own SQL, prefix any date fields with "ODDAT." so that the database can attempt to convert the date format for you.

== Double checking the changes with arsdoc query ==
Before proceeding to the next step, double check the changes you're about to make to the OnDemand Application Group, by testing your search criteria with the [[arsdoc query]] command. Only when you have the precise results you want, should you perform the arsdoc update command.

== Changing the data with arsdoc update ==
WARNING: There is no 'undo' command for arsdoc update. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running arsdoc update. If a CMOD database backup isn't reasonable, then have your DBA create a backup of the CMOD management tables (starting with 'ARS', and Application Group tables, so they can be restored without having to resort to a full database outage.

Formulating the actual arsdoc update command is tricky, and takes practise to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.

== Testing the results of the change ==
After the change is complete, then perform the query again, to ensure the changes have been made according to your wishes. Also, query some other documents to ensure that you change only affected the documents you intended to change.

← Older revision		Revision as of 01:00, 12 May 2020
Line 1:		Line 1:
	{{TOCright}}		{{TOCright}}
	In IBM ~~CMOD~~, the arsdoc update command is used to change index values of data that is already loaded. This may be used to update a status field used for workflow or tracking, but should not be used to update index data used to search for documents, as you ~~could render documents irretrievable~~.		In IBM Content Manager OnDemand, the <code>arsdoc update</code> command is used to change index values of data that is already loaded. This may be used to update a status field used for workflow or tracking, but '''should not be used''' to update index data used to search for documents. If you have incorrect document metadata, your first and only solution should be to unload the data from CMOD, and request a new file from the line of business, department, or vendor that created it. Modifying metadata should be an absolute last resort, as making changes to metadata calls into question the reliability of your archive. It will also be said many times in this article -- a mistake in your execution of the arsdoc update command can irrecoverably corrupt the metadata for documents in CMOD. Ensure that you have fresh backups of the entire database, and the tables you're modifying.

	If you are being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to ~~force~~ IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.		Again, if you are a OnDemand Administrator being asked to correct index data due to a data quality issue, the solution should be to improve data quality, NOT to require IBM CMOD to change index data. The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.

	[[File:Attention.png\|100px\|left]] WARNING: It is not just possible, but extremely easy to irrecoverably damage the data in your Content Manager OnDemand server with the arsdoc update command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!		[[File:Attention.png\|100px\|left]] WARNING: It is not just possible, but '''extremely easy''' to irrecoverably damage the data in your Content Manager OnDemand server with the <code>arsdoc update</code> command. The examples below are meant as a guide only, and you are solely responsible for any damage to your OnDemand server. Practice makes perfect!

	== Preparing to run arsdoc update ==		== Preparing to run arsdoc update ==
	Before running arsdoc update, you need to complete two steps. First, ~~create a new folder that consists only of~~ the ~~fields~~ you ~~wish to search~~ and ~~update using~~ the ~~arsdoc update command. Second~~, ~~ensure that you have permissions to access~~ the ~~folder~~, and ~~permissions to update~~ the fields in the ~~SINGLE~~ Application Group ~~that require changes~~.		Before running <code>arsdoc update</code>, you need to complete two steps. First, identify the Folder or Application Group you will be modifying, and understand the structure -- identify the Folder field names, or Application Group field names, plus the type of data and format of dates fields, and make sure that the fields you'll be changing have the 'Updatable' flag checked in the Application Group Configuration.
	[[File:ArsdocUpdate-EnablingChanges.png\|700px\|center\|Enabling Index Data Changes for Application Groups & Folders]]		[[File:ArsdocUpdate-EnablingChanges.png\|700px\|center\|Enabling Index Data Changes for Application Groups & Folders]]

	== Create the search criteria for arsdoc update ==		== Create the search criteria for arsdoc update ==
	There are two ways to create the criteria that will be used to execute the change. You can perform a search of your new folder, and save the search parameters as a '~~named query~~' in the Content Manager OnDemand Windows 'Thick Client', or ~~manually create an SQL statement that finds~~ the ~~specific documents you're looking to change~~.		There are two ways to create the criteria that will be used to execute the change. You can perform a search of your new folder, and save the search parameters as a 'Named Query' in the Content Manager OnDemand Windows 'Thick Client', or format your search for <code>arsdoc</code> using the same parameters as [[arsdoc_query]].

	Insert diagram here - creating a named query		Insert diagram here - creating a named query

	=== Date formats when using arsdoc update ===		=== Date formats when using arsdoc update ===
	IBM Content Manager OnDemand date formats are always tricky - it's best to use the date format specified in the folder definition when creating the parameters for your arsdoc update commands. If you ~~write your own SQL~~, ~~prefix any date fields with "ODDAT." so that the database can attempt~~ to ~~convert~~ the date format ~~for you~~.		IBM Content Manager OnDemand [[Date_and_Time_formats_in_Content_Manager_OnDemand\|date formats]] are always tricky - it's best to use the date format specified in the folder definition when creating the parameters for your <code>arsdoc update</code> commands. If you choose to update the Application Group, you'll need to understand the underlying date/time format in order to make a successful change.

	== Double checking the changes with arsdoc query ==		== Double checking the changes with arsdoc query ==
	Before proceeding to the next step, double check the ~~changes~~ you'~~re about to make to the OnDemand Application Group,~~ by testing your search criteria with the [[~~arsdoc query~~]] command. ~~Only when you have~~ the ~~precise results~~ you want, should you perform the arsdoc update command.		Before proceeding to the next step, double check the documents you'll be modifying by testing your search criteria with the [[arsdoc_query]] command. When <code>arsdoc query</code> returns ONLY the documents you want to modify, should you perform the <code>arsdoc update</code> command.

	== Changing the data with arsdoc update ==		== Changing the data with arsdoc update ==
	[[File:Attention.png\|100px\|left]] WARNING: There is no 'undo' command for arsdoc update. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running arsdoc update. ~~If an IBM CMOD database backup isn't reasonable, then have~~ your DBA ~~create a backup~~ of the OnDemand management tables (starting with 'ARS'), and Application Group tables, so they can be restored without ~~having to resort to~~ a ~~full~~ database outage.		[[File:Attention.png\|100px\|left]] WARNING: There is no 'undo' command for <code>arsdoc update</code>. The changes you're requesting are usually made in a fraction of a second, and there will be no way to revert the change back to the original state. It is a wise and prudent move to create a full, offline database backup immediately before running <code>arsdoc update</code>, as well as exporting unmodified copies of your tables to revert changes with relative ease. Contact your local DBA for assistance in creating backups of the OnDemand management tables (starting with 'ARS'), and Application Group tables that will be modifed, so they can be restored without requiring a database outage for a full restore.

	Formulating the actual arsdoc update command is tricky, and takes ~~practise~~ to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.		Formulating the actual <code>arsdoc update</code> command is tricky, and takes practice to get right. Your command should be tested on non-production OnDemand servers, and verified to be providing the correct results BEFORE executing them in a production environment.

	== Testing the results of the change ==		== Testing the results of the change ==
	After the change is complete, then perform the query again, to ensure the changes have been made according to your wishes. Also, ~~query some~~ other documents to ensure that you change only affected the documents you intended to change.		After the change is complete, then perform the <code>arsdoc query</code> command again, to ensure the changes have been made according to your wishes. Also, using the CMOD Thick Client, search for other documents to ensure that you change only affected the documents you intended to change.