Informatica Standards - Revision history

Admin: Fixed Naked
element

2008-04-09T20:34:35Z

Fixed Naked <LI> element

← Older revision		Revision as of 20:34, 9 April 2008
Line 16:		Line 16:
	<LI>Where should shell script redirects to log files be? In the Informatica command task that calls them? Should the script handle its own log file? If a BTEQ script is called from a shell script, should the shell script handle the BTEQ log but something else handle the shell script log? Or should the BTEQ just pass through stdout and stderr to the script, which is then redirected by Informatica?		<LI>Where should shell script redirects to log files be? In the Informatica command task that calls them? Should the script handle its own log file? If a BTEQ script is called from a shell script, should the shell script handle the BTEQ log but something else handle the shell script log? Or should the BTEQ just pass through stdout and stderr to the script, which is then redirected by Informatica?
	</LI>		</LI>
	<LI>There's some issue with the XML Parser that it doesn't always generate rows if some of the nested elements are missing. There's a "Force Row" check box in the source XML editor which alleviates this problem. I'll have a picture up around here about it sometime.		<LI>There's some issue with the XML Parser that it doesn't always generate rows if some of the nested elements are missing. There's a "Force Row" check box in the source XML editor which alleviates this problem. I'll have a picture up around here about it sometime.</LI>
	</UL>		</UL>

Admin: /* Good Standards */

2008-04-09T20:34:10Z

Good Standards

← Older revision		Revision as of 20:34, 9 April 2008
Line 9:		Line 9:
	<LI>Use Admin Tables: ADMIN_FEED_TO_TABLE, etc. (needed for checking MLoad errors, etc.)</LI>		<LI>Use Admin Tables: ADMIN_FEED_TO_TABLE, etc. (needed for checking MLoad errors, etc.)</LI>
	<LI>Set Error Threshold to 1 in MLoad configuration. This does NOT mean you can avoid a separate check for MLoad errors; UV errors are not properly reported back to Informatica, but ET errors will at least fail the load</LI>		<LI>Set Error Threshold to 1 in MLoad configuration. This does NOT mean you can avoid a separate check for MLoad errors; UV errors are not properly reported back to Informatica, but ET errors will at least fail the load</LI>
			<LI>Ensure workflow and session logs are directed to the appropriate directory, as the default is not precise enough</LI>
	</UL>		</UL>

Admin: /* Discussion Items */

2007-08-31T04:23:37Z

Discussion Items

← Older revision		Revision as of 04:23, 31 August 2007
Line 15:		Line 15:
	<LI>Where should shell script redirects to log files be? In the Informatica command task that calls them? Should the script handle its own log file? If a BTEQ script is called from a shell script, should the shell script handle the BTEQ log but something else handle the shell script log? Or should the BTEQ just pass through stdout and stderr to the script, which is then redirected by Informatica?		<LI>Where should shell script redirects to log files be? In the Informatica command task that calls them? Should the script handle its own log file? If a BTEQ script is called from a shell script, should the shell script handle the BTEQ log but something else handle the shell script log? Or should the BTEQ just pass through stdout and stderr to the script, which is then redirected by Informatica?
	</LI>		</LI>
			<LI>There's some issue with the XML Parser that it doesn't always generate rows if some of the nested elements are missing. There's a "Force Row" check box in the source XML editor which alleviates this problem. I'll have a picture up around here about it sometime.
	</UL>		</UL>

Admin: /* Good Standards */

2007-08-24T22:45:09Z

Good Standards

← Older revision		Revision as of 22:45, 24 August 2007
Line 7:		Line 7:
	<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>		<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>
	<LI>Scripts should always write to <stdout>; only the highest level call should redirect to a log file with "> <log> 2>&1" style</LI>		<LI>Scripts should always write to <stdout>; only the highest level call should redirect to a log file with "> <log> 2>&1" style</LI>
			<LI>Use Admin Tables: ADMIN_FEED_TO_TABLE, etc. (needed for checking MLoad errors, etc.)</LI>
			<LI>Set Error Threshold to 1 in MLoad configuration. This does NOT mean you can avoid a separate check for MLoad errors; UV errors are not properly reported back to Informatica, but ET errors will at least fail the load</LI>
	</UL>		</UL>

Admin: /* Good Standards */

2007-08-22T20:18:58Z

Good Standards

← Older revision		Revision as of 20:18, 22 August 2007
Line 6:		Line 6:
	<LI>Always check "Run if previous completed" on command tasks</LI>		<LI>Always check "Run if previous completed" on command tasks</LI>
	<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>		<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>
			<LI>Scripts should always write to <stdout>; only the highest level call should redirect to a log file with "> <log> 2>&1" style</LI>
	</UL>		</UL>

Admin: /* Good Standards */

2007-08-17T03:46:21Z

Good Standards

← Older revision		Revision as of 03:46, 17 August 2007
Line 4:		Line 4:
	<LI>Always set the error threshold to 1</LI>		<LI>Always set the error threshold to 1</LI>
	<LI>Always check "fail parent if this task fails"</LI>		<LI>Always check "fail parent if this task fails"</LI>
			<LI>Always check "Run if previous completed" on command tasks</LI>
	<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>		<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>
	</UL>		</UL>

Admin: /* Good Standards */

2007-08-14T22:58:53Z

Good Standards

← Older revision		Revision as of 22:58, 14 August 2007
Line 3:		Line 3:
	<UL>		<UL>
	<LI>Always set the error threshold to 1</LI>		<LI>Always set the error threshold to 1</LI>
			<LI>Always check "fail parent if this task fails"</LI>
	<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>		<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>
	</UL>		</UL>

Admin at 22:53, 14 August 2007

2007-08-14T22:53:18Z

New page

=Informatica Standards and Thoughts=
==Good Standards==
<UL>
<LI>Always set the error threshold to 1</LI>
<LI>Try to avoid overriding reuseable Tasks and Sessions... if you get a "Revert" button while making a change, make sure the change should only apply to THIS instance, rather than every instance, and consider making the change in another place.</LI>
</UL>

==Discussion Items==
<UL>
<LI>Where should shell script redirects to log files be? In the Informatica command task that calls them? Should the script handle its own log file? If a BTEQ script is called from a shell script, should the shell script handle the BTEQ log but something else handle the shell script log? Or should the BTEQ just pass through stdout and stderr to the script, which is then redirected by Informatica?
</LI>
</UL>

Informatica Standards - Revision history

Admin: Fixed Naked element

Admin: /* Good Standards */

Admin: /* Discussion Items */

Admin: /* Good Standards */

Admin: /* Good Standards */

Admin: /* Good Standards */

Admin: /* Good Standards */

Admin at 22:53, 14 August 2007

Admin: Fixed Naked
element