Sage 100

I created a VI job to import lines from Excel (.xlsx) file into PO in 4.40. Worked fine on my system. Transferred file and VI job to client's system (also running Excel 2007) and get ""Error 88 in program VI_IMPORT_UI.PVC at line 0984"". Line 0984 is where VI tries to open the file. This happens on multiple workstations, and with multiple Excel files (all of which open fine in Excel). I manually recreated the VI job just in case the .exp file somehow got hosed in transit, same error. Any ideas?

Try it in CSV

My first guess would be users permissions.

The user can open the file in Excel, and she is a domain admin I don't think it is permissions. I am trying avoid the csv route as users would have to make sure it went from Excel to csv with tab as the delimiter and no text delimiter as their are commas, single and double quotes (inches and feet) in many of the descriptions being imported (these are shop supplies and repair parts ordered as * items).

Error #88: Invalid/unknown property nameThe property or method name of a ProvideX object (OOP object/OCX/COM/VBXcontrol or GUI control) is invalid, or the parameters passed to a method call are incorrect. My guess it that the object doesn't understand the file you have. Have you tried to save the file as xls instead of xlsx? Personally, I almost always save and use files as CSV like @WayneSchulz suggested. I get more consistent results.

Every consultant calls me names when I say that Excel usually doesn't work. A client just fired me (yes I got fired over a friggin VI job) for advising them on my best practices experiences. However I swear that my imports always go smoother when CSV is the source.

I agree with Wayne - I always use CSV files.

Ditto on the CSV!

Guess I won't pile on then. Tab delimited is my choice. We run into these types of issues when delivering an Access database solution. Works great on my programmers computer. Works great on my computer for QC testing. Tanks at the customer's site with their installation of Access. We look like idiots. Totally sucks.

Is your system and the client's system on the same PU? Also, are the installed modules the same on both systems?

I have too up until now - was just hoping there was a way to get Excel to actually work, since I know I'll get calls about this as csv when the csv save isn't configured correctly.

Regarding the consistent saving, what about a macro to invoke the save?

John, The only difference is the systems is mine is MAS90 and theirs is MAS 200 - same modules and mods.

Jeff, I like the macro idea. I just always feel awkward telling the users they have to be smarter than the programmers.

Do you have the job set up with On Host selected? If this is 200, it's relative to the server if that is not checked.

On host is not selected as users will have to select a different file for each use. I copied the UNC path out of VI and pasted into Run and the excel file opened.

On the server?

On the workstation, because the server does not have Excel installed, which is probably why this doesn't work (though I got a different message when I tried to being up the VI job on the server itself).

Try a mapped drive just to rule out the UNC...........

UPDATE: Success! Apparently buried in the release notes for a ""product update"" in which the xlsx option first appeared is a note that when you use the new Excel format, you must check the ""on host"" box even if the file will be accessed from the workstation, because VI does not directly import Excel. Instead it makes a text file from it in ../MAS90/home/textout on the server and imports that. Now why they couldn't just program it so that if file type = Excel12 then ""on Host"" = true I don't understand. Guess this is part of the plan for making support a profit center.

Good Tip