We need the pdm_load and\or pdm_userload functionality to be extended to work like GRLoader, and read data directly from an Excel file or csv; and to have an ODBC driver to do the same thing from database-sourced data.
If I try to combine all comments above then I guess we are looking for a functionality/utility that can process a csv/Excel file and load the data into CA SDM, with a switch to bypass the object layer or not, and with useful error/issue output.
The file could contain records that need inserting and others that need updating and this for any object.
Using any field as a key for the data load seems to be another important element (e.g. using userid for cnt, or maybe e-mail address in another load, depending on what you have at hand or what your customer provides).
This idea is being Wish-Listed for potential inclusion in a future release.
Before this idea moves to the next stage (Currently Planned or Not Planned), I would like to invite community members to please provide additional input and/or vote. Please note that Wish-listed ideas are selected for inclusion in a release based on multiple factors including - number of votes from community members, alignment of idea with a release's themes and goals, complexities and risks involved in implementing the idea, so a timeframe for availability of the idea as a product feature/functionality cannot be provided. Additionally, the implementation of your idea may not be exactly as requested and/or may be delivered in a new user experience.
SUPER GRLOADER (z_loader_sdm_v103_en.zip)
Agree for a new utility as mention by Andholmes.
don't like to use pdm_load as this is bypassing object with no check at all and may result of corrupt data.
We internally have crated a small utility that read tab delimited text file and load the data using WS.
This way we are sure that any business logic is applied to the dat
This will make loads much easier and less mistakes
I Agree. Great Idea.
Extending this idea, I suggest to looking for Create GUI for GRLoader/ADT for CMDB
Try directing both STDOUT and STDERR to the log. Sounds like they print the status to STDOUT and the individual prints to STDERR.
I would vote for a new utility. We like the fact that this bypasses the object layer and does not trigger notifications, etc. However, we would like to see the output from the -v switch be available to pipe to a log file. When we use pdm_load -v -f example.txt > error.log , the only thing you get in the error.log is a statement that shows the file was loaded. When you are loading more than 5 records, the information about the 1 record that contained an error is off the screen and you cannot see it.
Passing through the object layer is rather vital for this. Not sure if the pdm_(user)load should change, maybe introduce something alongside and call it something like "pdm_objectload"?
I am fairly certain that the current approach for pdm_load and pdm_userload behavior is use to their use by that application directly - hence the reason that it does things like bypassing the object layer. As such, some of the inherent behavior would be especially difficult to alter without doing massive changes to the underlying application. Would you get the necessary value if instead of changing the existing utilities, we focused on some new capabilities for data load?
Agreed and Voted!
Will vote for your idea
One of the most important reasons why we typically do not user pdm_load/userload too much is because the data is not sent through the object layer. This means that any triggers are not fired when using these command line tools. We developed our own dataload tool to overcome all this. So if CA want to extend pdm_load/userload then we are all for it, but we would love to see it take the object layer into consideration as well. Another nice improvement would be to do away with the deref-ing and being able to do both inserts and updates from one dataload file, on any field you chose to be the key, or any combination of fields for that manner.