Anybody have any real world experience with the Datastage add-ons for Peoplesoft? Curious as to how much folks get out of it. Thanks much.
ART
Add-ons for Peoplesoft - Thoughts, experience, or comments.
Moderators: chulett, rschirm, roy
If you need any real world experience with Peoplesoft in general - without the use of any add-on pack - let me know. We've had plenty lately. More than plenty, actually. 
Maybe the add-on would have helped... but then I have no idea what it brings to the table. We've been accessing it 'raw', so to speak... and it's been leaving a funny taste in my mouth.
Maybe the add-on would have helped... but then I have no idea what it brings to the table. We've been accessing it 'raw', so to speak... and it's been leaving a funny taste in my mouth.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
It's been interesting as a data source... off the top of my head:
* There are almost 19,000 tables in our source instance
* All tables are owned by SYSADM
* They use LONG fields for comments
* DATE fields are inconsistantly populated
* Date integrity issues between related tables
It been fun to discover things like date fields which occassionally have a time portion. When these date fields are across related tables, most of the time both fields will carry the same time portion but occassionally they will *not* be the same. Needless to say, when these date fields are used in a FK constraint, joins fail to return all of the rows that they should. Even if I join using a TRUNCated date my problem isn't completely solved as there are other integrity issues I am still trying to track down with the people responsible for the system.
LONGs are a PITA to deal with. You can see "OCI has fetched truncated data" errors and piss-poor performance with those fields in your queries. I get the impression they have nicely fomatted multi-line screens for comments (never actually seen the system in action) so sometimes people will put tabs or hard returns in their comments to make them line up all purty on the app screens. Write those out to a flat file and things can get a little goofed up.
Peoplesoft tables are some of the "longest" I've dealt with so far. It is normal for a table to have 200, 300 or more fields in it. I use TOAD as my tool of choice and the data grid seems to "lock up" for moments at a time as it struggles to strip down or build up these huge row sizes for display. Combine that with the fact that my source system is half-way across the country from my DataStage server and PC and there are times where I wait for it to simply fetch the list of columns for a particular table.
Oh, and when there's that many tables in your system, it's hard to track down the person who knows about the three or four tables you need to know about at any particular moment.
Stuff like that.
* There are almost 19,000 tables in our source instance
* All tables are owned by SYSADM
* They use LONG fields for comments
* DATE fields are inconsistantly populated
* Date integrity issues between related tables
It been fun to discover things like date fields which occassionally have a time portion. When these date fields are across related tables, most of the time both fields will carry the same time portion but occassionally they will *not* be the same. Needless to say, when these date fields are used in a FK constraint, joins fail to return all of the rows that they should. Even if I join using a TRUNCated date my problem isn't completely solved as there are other integrity issues I am still trying to track down with the people responsible for the system.
LONGs are a PITA to deal with. You can see "OCI has fetched truncated data" errors and piss-poor performance with those fields in your queries. I get the impression they have nicely fomatted multi-line screens for comments (never actually seen the system in action) so sometimes people will put tabs or hard returns in their comments to make them line up all purty on the app screens. Write those out to a flat file and things can get a little goofed up.
Peoplesoft tables are some of the "longest" I've dealt with so far. It is normal for a table to have 200, 300 or more fields in it. I use TOAD as my tool of choice and the data grid seems to "lock up" for moments at a time as it struggles to strip down or build up these huge row sizes for display. Combine that with the fact that my source system is half-way across the country from my DataStage server and PC and there are times where I wait for it to simply fetch the list of columns for a particular table.
Oh, and when there's that many tables in your system, it's hard to track down the person who knows about the three or four tables you need to know about at any particular moment.
Stuff like that.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers