LJ, I just worked a ticket w/ BMC on this to be sure. Server-side dataimporttool won't work for non-administrator userids if already logged-in to Remedy, which is the case if you trigger the import via workflow. (Posting to clarify for anybody who may be interested - it's painful to get a straight answer from BMC support).
We have an application that needs Submitter set to the importing user, and we want to keep Submitter-mode locked. As a workaround, we implemented a sed script to edit a copy of the import map file, substituting $USER$ with current userid; then use the map file copy instead of the original in the java call. Cheesy, but workable. Mike White EMail michael.wh...@verizon.com<mailto:michael.wh...@verizon.com> Office 813.978.2192 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Monday, January 31, 2011 3:06 PM To: arslist@ARSLIST.ORG Subject: Re: 7.6.03 dataimporttool userid validation issue (9093 error) ** Mike, For our server side import scripts we usually use an admin account to avoid this type of error. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of White, Michael W (Mike) Sent: Monday, January 31, 2011 12:39 PM To: arslist@ARSLIST.ORG Subject: 7.6.03 dataimporttool userid validation issue (9093 error) ** Arslist, We upgraded from 7.0.1 to 7.6.3 about a week and a half ago (Oracle 10g database on a Solaris 5.10 server). We have a few applications that import external data to various forms, controlled by records in a central form. User attaches external file to control record and sets an "import" check-box field. A triggered Filter detaches the file to our server and executes a script to run the import, providing necessary arguments. In some applications, we use -u and -p import options for userid and password. When we do, we're now seeing 9093 errors - User is currently connected from another machine. Only for non-administrator userids, regardless of fixed or floating write license type. Presumably it's due to the IP addresses of the user's workstation and our server. We're tried the -v option to "force override" (Integration Guide, p. 243), but it didn't seem to have any affect. By any chance, have any of you seen this behavior? Thanks in advance for any light you can shed... Mike White EMail michael.wh...@verizon.com<mailto:michael.wh...@verizon.com> Office 813.978.2192 _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"