Andy,

Thank you for sharing that, most useful. Had a very similar problem with an RLL, but with Enterprise Manager/MMC on a test machine. This was very easy to pinpoint, as I caused it myself (!) whilst doing an install of a new piece of software. Problem was that the code relied on SQL-DMO, and I had inadvertently included the SQL Server 7.0 SQL-DMO library in the install package, instead of the SQL Server 2000 DMO library. D'oh.

The installer I was using was InstallShield (no reflection on the product, I think it's great), though accidentally picking the wrong library is I guess something you could easily do with any vendor's installation package. Did exactly the same to fix it as yourself, copied across the RLL from another box and it worked fine. Re-installed the package again and it broke it, so I knew for certain it was the culprit. Re-built the package with the SQL Server 2000 SQL-DMO and re-installed it again, worked this time, no issues. I'd suggest you install the same package you've had problems with on a test box with the same NT/SQL Server version/service pack, and see if it breaks that. Bet it will 🙂

Looks like the problem you've experienced is with a local language resource file for the ActiveX Scripting Host, guess the package that you installed was doing something related to DTS ? If so, check out :

http://sqldts.com/default.aspx?6,105,225,0,1

and

http://www.linxent.com/articles/DTS%20Package%20Files%20Needed%20for%20VB.htm

There's also a useful note from Microsoft concerning Axscphst.dll which may impact the .rll at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dtssql/dts_addf_ax_06er.asp

(note that there's an error in the regsvr32.exe example they give, end of line should read Binn\axscphst.dll...)

Probably an incompatibility between the version of the DTS lib. you're installing from the install package, and the one on the target box that's caused the problems. These problems can be really juicy and very time consuming if you're developing for a large combination of target NT/SQL/service pack environments.

As an aside, I love VMWare (www.vmware.com) as it means that new packages can be tested easily, and the original machine image can be 'rolled back' to an operational state if there are any problems - very cool, saves huge amounts of time, especially if you do any SQL Server related development. Recommended.

Edited by - jonreade on 07/09/2003 02:00:00 AM