Search Results

Search found 2 results on 1 pages for 'kcrumley'.

Page 1/1 | 1 

  • How to solve "catastrophic failure" with 32-bit COM component in SysWOW64\cscript or wscript

    - by kcrumley
    I'm trying to run a VBScript script that uses a 7-year-old 3rd-party 32-bit COM component on Windows Server 2008 R2, with the command-line 32-bit script host, SysWOW64\cscript.exe. When I call CreateObject on the class, it appears to be successful, but the very first time I try to use a property or method (I've tried several different ones) on the object, it gives me the "catastrophic failure". I have identical results with SysWOW64\wscript.exe, except, of course, that my error message comes in a msgbox instead of the command-line window. I think this has to do specifically with the 64-bit scripting hosts because of the following: The equivalent Classic ASP script, calling the same component and using 95% of the same code, works correctly on the same server, with IIS configured to support 32-bit COM. The same VBScript works correctly on a 32-bit Windows XP machine and a 32-bit Windows Server 2003 machine. The component fails in exactly the same way on my 64-bit Windows 7 machine. My Google searches for solutions to this problem have mostly turned up a lot of different problems that were solved by putting the COM component into a toolbar in Visual Studio. Obviously, that solution doesn't apply here. My questions are: Is there a core problem that is always behind a "catastrophic failure" from a Windows scripting host calling a COM component? Is there a place in a configuration snap-in, or in the registry, where I need to make a change similar to the change I had to make to the IIS Application pool to "Enable 32-bit Applications"? Is there a general place in the Server 2008 R2 Event Viewer that I should be looking, to see if there are any more details on the failure, in case it turns out to be specific to this component? Thanks in advance.

    Read the article

  • Selecting data in clustered index order without ORDER BY

    - by kcrumley
    I know there is no guarantee without an ORDER BY clause, but are there any techniques to tune SQL Server tables so they're more likely to return rows in clustered index order, without having to specify ORDER BY every single time I want to run a super-quick ad hoc query? For example, would rebuilding my clustered index or updating statistics help? I'm aware that I can't count on a query like: select * from AuditLog where UserId = 992 to return records in the order of the clustered index, so I would never build code into an application based on this assumption. But for simple ad hoc queries, on almost all of my tables, the data consistently comes out in clustered index order, and I've gotten used to being able to expect the most recent results to be at the bottom. Out of all the many tables we use, I've only noticed two ever giving me results in an unpredicted order. This is really just an annoyance, but it would be nice to be able to minimize it. In case this is relevant because of page boundary issues or something like that, I should mention that one of the tables that has inconsistent ordering, the AuditLog table, is the longest table we have that has a clustered index on an identity column. Also, this database has recently been moved from SQL 2005 to SQL 2008, and we've seen no noticeable change in this behavior.

    Read the article

1