Strange issue with sp_OAMethod

  • My procedure creates a COM object with sp_OACreate. Then it uses the sp_OAMethod to call a "load" method of the underlying DLL. Finally it uses sp_OADestroy to dispose the COM object.

    The procedure works perfectly fine the first round.

    During the second round of execution, sp_OACreate succeeds. But sp_OAMethod returns insufficient memory error. I was under the impression that sp_OADestroy would have released the memory, but that doesn’t seem to be the reality.

    I tried the following commands after the first round of execution

    DBCC DROPCLEANBUFFERS

    DBCC FREEPROCCACHE

    DBCC FREESESSIONCACHE

    DBCC FREESYSTEMCACHE (‘ALL’)

    But none of them (nor all of them together) help.

    The only way out is to restart the SQL Service after each round of execution.

    Is there a way around this?

  • Quick google search threw up this:

    http://support.microsoft.com/kb/937277

    Have you considered / checked?

  • Yes had viewed this. But we use SQL 2008, so I didn't think that was relevant. Didn't find any such fixes for 2008 / 2008R2.

  • Is the com object in-process(dll) or out-of-process (exe)?

    How much time between iterations?

    How much memory on the machine and how much is SQL allowed to use?

    I have had more problems than I can count with in-process com objects and out-of-process were just slightly less problematic..

    And if it is at all possible don't use com objects..

    CEWII

  • The COM is in-process (dll).

    System RAM: 15.9 GB

    Total Paging Size: 32000 MB

    Max SQL Server Memory (in MB): 2147483647

  • If the COM object is hung up in-process then restarting SQL is the only way to clear it.

    I found this http://support.persits.com/show.asp?code=PS051122152 it seems to use sp_oadestroy to destroy thing other than the object, I've not seen that before. I find a secondary similar reference http://www.cknotes.com/?p=437

    Also you really should set the max memory for you SQL Server, I would think in the 14-15GB range, depending on what else is running on that box perhaps as low as 13GB..

    CEWII

  • Can you switch from OLE Automation (sp_OA procs) to SQLCLR and COM interop? The .NET Framework being a managed environment you probably won't have any issues with hung in-process dlls.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • Switching/Redesign/Redevelopment is not a viable option as of now. I have to make this work somehow.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply