SQL Server Compact - Compact & Capable : Troubleshooting

Troubleshooting: Access Violation exception while using SQL Server Compact database with ADO.NET provider

SQLCEBLOG — Wed, 06 May 2009 06:26:00 GMT

Possible causes for Access Violation exception in general:

An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value.

In programs consisting entirely of verifiable managed code, all references are either valid or null, and access violations are impossible. An AccessViolationException occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.

For more information about this, please visit this link.

When this exception can be related to SQL Server Compact:

SQL Server Compact ADO.NET provider DLL [System.Data.SqlServerCe.dll] is a managed DLL which interacts with other native DLLs to provide the functionality.

There are two known issues related to the usage of SQL Server Compact provider which may lead to this Access Violation exception:

1. Version Mismatch [3.5 RTM and 3.5 SP1]:

Access Violation occurs when the loader loads different versions of Managed and Native SQL Server Compact 3.5 DLLs. This issue arises when different versions are available in the box and this happens with Private and Central deployment of SQL Server Compact 3.5.

To be specific, if SQL Server Compact 3.5 RTM is pre-installed [centrally deployed] in the box and application built on top of SQL Server Compact 3.5 SP1 privately deploys the SQL Server Compact DLLs.

In this case, the managed DLL [System.Data.SqlServerCe.dll v3.5.5692.0] will be loaded from private directory but the native DLLs [sqlceme35.dll, sqlceqp35.dll, etc. v3.5.5386.0] might get loaded from the central deployed directory.

If the application is built against SQL Server Compact 3.5 RTM and SQL Server Compact 3.5 SP1 is centrally deployed in the box then the application will start using SQL Compact 3.5 SP1 as there is a redirection entry which redirects an application (Compiled against 3.5 RTM) to use centrally deployed SQL Compact 3.5 SP1.

2. Thread Safety:

SQL CE objects are not thread-safe and are not thread affinitive either. If an instance of SqlCeConnection or SqlCeTransaction is shared across threads without ensuring thread safety, then that may lead to Access Violation exception.

Work-around if the cause is related to SQL Server Compact:

For the above two issues, there are workarounds available which should be followed to avoid any Access Violation exception.

1. Version Mismatch:

One should follow either of the given below approaches to avoid the Access Violation exception:

Scenario: Application built against SQL Server Compact 3.5 SP1 [to be deployed privately] and SQL Server Compact 3.5 RTM centrally deployed.

Solution:

1. There should be only one version of SQL Server Compact [v3.5 RTM or v3.5 SP1] installed in the box. The version with which the application is not built against [v3.5 RTM] should be un-installed.

2. Install SQL Server Compact [v3.5 SP1] centrally to avoid any future install mismatch.

Forum thread related to this issue can be found here.

2. Thread Safety:

It is recommended that each thread should use a separate connection than sharing across. If there is really a need for sharing SQL CE objects across threads, then the application should serialize access to these objects.

Thanks,

Mohammad Imran.

After moving the database from one platform to other, the first SqlCeConnection.Open() takes more time

SQLCEBLOG — Wed, 01 Apr 2009 15:16:00 GMT

If you move a SQLCE database from one platform to other, it's first SqlCeConnection.Open() takes more time and also increases the database file size.

The Reason: For an index on string type columns, SQLCE uses LCMapString API to get the normalized sort key. LCMapString API behavior will be different for different NLS sort versions. NLS sort version is different for Desktop Windows OS and WM/WCE. During the first database connection open, SQLCE rebuilds all indexes if there is a NLS sort version mismatch with the last accessed OS platform. Index recreation requires space on database file and hence the database file size will be increased. You can use Compact()/Shrink() API to get the database file with approximately old file size. Because of this index recreation, first database connection open takes more time as it has to rebuild all indexes.

Note: If your database doesn’t have any indexes you will not see above mentioned symptoms on first connection open.

Don’t inter-op SQLCE 3.0 databases between devices and desktop:

SQLCE started supporting desktops only from SQLCE 3.1 (3.0.5300.0) release. SQLCE 3.0 doesn’t have index rebuilding logic and the index re-creation was added during SQLCE 3.1 (3.0.5300.0) release as it is required to support platform inter-op for SQLCE databases. On desktop you can open SQLCE 3.0 databases, which were created on devices. Again If you open these databases on SQLCE 3.0 devices, your device app might receive an error/exception.

For example: Opening a SQLCE 3.0 database with SSMS will use SQLCE 3.1 bits on desktop and hence it would drop and recreate index data. When this file is copied back to device, index data may not be valid and receive an error/exception.

Namaskaram!

Manikyam Bavandla

Insight into SQL Server Compact database corruptions

SQLCEBLOG — Wed, 25 Jun 2008 18:20:00 GMT

Database corruptions are often the most painful bugs to repro and debug. A good percentage of the SQL Server Compact bugs reported are in this category. However it so turns out that in majority of the cases Compact is not the culprit. Surprised!! Let us see why.

How SQL Server Compact detects a file corruption?

Compact database comprises of a series of pages, each 4K in size. When a page is written to disk the following sequence of steps is executed.

1. Compute the checksum on the page data and store it as part of the page.

2. Encrypt the page.

3. Write to disk at a given file location or offset.

4. Update system pages/run time cache with the page offset.

When a page is read from disk the following sequence of steps is executed.

1. Read from the disk.

2. Decrypt the page.

3. Re-compute the checksum and compare it with the expected value. (If it fails page is not fully baked. Meaning file write failed)

4. Check if this is the same page that we are expecting as per the system pages/ run time cache. (If this fails we lost a complete page write)

If (3) or (4) of the above read steps fail, the db is marked as corrupt and any further db activity is suspended till it is repaired successfully.

Notes:

· Verify reports step (3) errors as “Bad Checksum - idPage: %d, tyPage: %d, iPage: %d”.

· Verify reports step (4) errors as “Page with valid ordinal not found - idPage: %d, iPage: %d”

What could have triggered the corruption?

1. A simple device on/off or suspend/resume can result in half-baked file. (No reason to panic as we handle this as described in the next section.)

2. Compact relies on underlying FAT/TFAT file system to manage the database file. Any bugs in these components can lead to Compact file corruption. Compact stresses file system in many different ways as it tries to keep the file size as small as possible. As it employs shadow paging the writes and reads are quite random. (Note: 6 months back a bug has been identified in FAT/TFAT system that results in a Compact file losing some of the clusters during shrink operation.)

3. If SD card is being used for db file storage, it’s being equally stressed as the above.

4. More importantly SD cards bring in additional complexities during Suspend/Resume cycles. Here is a good blog link: http://blogs.msdn.com/windowsmobile/archive/2007/01/12/everything-you-want-to-know-about-sd.aspx

Am I suggesting SQL Server Compact bugs can’t result in any kind of corruption?

Of course Compact code bugs can result in corruption. A lot of them have been found internally before v3.0 release and also reported by customers thereafter. They are more logical in nature like index constraint is compromised or a table page says there are 1000 rows when there are only 55. We did a very good job in fixing these and they are hard to find now. However Compact bugs don’t result in physical corruptions like “checksum errors” or “page missing” errors.

What does Compact do to prevent corruptions?

We believe most of the corruptions should be due to device suspend/resume or on/off cycles. For ex: Compact is trying to write to a file and the user simply boots his device. Now file is in half-baked state. Or let’s say process gets killed before it can complete the flush cycle. How do we avoid this?

Well, we use shadow paging to overcome this situation. We can loosely categorize the db pages into user data pages, system pages and header page. As the name suggests user data pages contain all the user data. Header pages and system pages help us locate a specific user page on the disk. When it’s time to flush the changes to disk, we write shadows of the user data pages first. Then the shadows of the updated system pages are written. Finally the header page is written. The old pages are retained till the header page is updated. This ensures that we have a transactional write to the disk. Either the change is completely present or not.

Conclusion: Why do we still see corruptions?

Clearly the above is not enough. Some of the interesting cases are

· What if any of the underlying systems ‘SD card software’ or FAT/TFAT has a bug?

· Suspend/resume cycle can result in file buffer loss if SD card is used. So the changes supposed to be written to disk could be lost.

The intent is not to blame other components. However in the last 3 years, at least 90% of the corruption bugs reported are due to bad checksum. It means disk write is bad for some reason (which is not owned by Compact). The fault is somewhere in the bottom stack and it has to be fixed. Our options are very limited without a repro but we are trying hard to improve our debugging infrastructure. We are hoping that with this knowledge customers will be able to understand the corruptions better and come up with good practices that would vastly reduce these corruptions.

Thanks

Raja

Query performance

SQLCEBLOG — Wed, 30 Apr 2008 08:15:00 GMT

Understanding the reason for slowness of a SQL query and then tuning to boost it is a slightly complicated process, but it can be extremely rewarding in some cases. In this post, I am going to list down some ways in which you can tune the query performance for SQL Server Compact, along with pointers to relevant online resources. If you are a seasoned database developer, you probably know most of the tricks already.

Before I jump into it, an overview of the basics first.

Basics:

Displaying actual and estimated Execution plans for SQL Server Compact: You should be familiar with Execution Plans (also called as query plans and showplans).

For non-parameterized queries: There are several easy ways to do this

When database is on a docked device or desktop: Generate a query plan using SQL Server Management Studio (SSMS) that gives a nice graphical view of the query plans. (You can connect to the database on device as long as it is docked. No need to copy the file to desktop.)
When database is on a device: Generate a query plan using Query Analyzer. This generates a .sqlplan file that can be viewed graphically in SQL Server Management Studio as before (preferable) or opened as a plain XML file.

For Parameterized (as well as non-parameterized) queries:

Use the TSQL Statements SET SHOWPLAN_XML (for estimated execution plan) and SET STATISTICS_XML (for actual execution plan), followed by SELECT @@SHOWPLAN to generate the query plans. Store the results as an XML file. (Tip: To view the query plans graphically, just rename the file with a .sqlplan extension and it is ready to be opened in SSMS like an ordinary non-parameterized query plan.)

Indexes and statistics on indexes:

One of the important tasks of the query optimizer is to select the right index to execute the query. An optimizer can make better decisions if it has histogram data (i.e. statistics) about the distribution of values for an index.

CREATING/UPDATING/DELETING statistics on an index: SQL Server Compact 3.5 creates statistics on all indexes by default and updates them as required. (You can surely tweak these settings, but it is advisable not to. See CREATE STATISTICS /UPDATE STATISTICS/DROP STATISTICS).
To view the statistics distribution, the built in stored procedure sp_show_statistics is pretty handy.
Statistics were not created by default on primary key indexes till version 3.1, so you might want to check this and add them yourself :- ).

... A lot of other things too J, but this will do for the time being.

The Meat:

If you are trying to improve the performance of your application that uses SQL Server Compact, make sure you have checked the following resources on MSDN already (In this post I will not go into any of them):

Database Design and Performance: This page talks in some detail about the following:

Database denormalization
Variable and fixed sized columns
Effect of row and key lengths

Query Performance Tuning: This page explains some of the following:

Improving indexes by creating selective indexes, choosing the columns in a multi-column index, issues in indexing a small table etc.
When to create indexes
Using parameterized queries where possible.
Rewrite queries where possible
Using base table cursor (CommandType.TableDirect) mode for simple queries.

(The article on Query Process Overview and Performance Tuning approaches for SQL Server CE 2.0 covers the same points as above, but I found it better than the MSDN links J. It is relevant for SQL Server Compact 3.5 too.)

Now here are some additional ways you can improve performance:

1. Recompile Stale query plans

<StoryTime>Sometime back I got a complaint about slow performance of our database even though the user was using parameterized queries and had created the correct indexes everywhere. The sequence in which he was performing operations was something like this:

- Create the full database schema (tables, indexes etc).

- Prepare SqlCeCommand objects for *all* queries that will ever be used by the application.

- Populate the database with actual data. Until now all tables were empty.

- Execute the queries using previously prepared command objects

What's wrong with this?

A prepared command object (SqlCeCommand) holds a query plan. The query optimizer generated this query plan and had optimized it for the state of database when the plan was generated. In this user's case, the database had just empty tables at that point in time. The optimizer therefore inferred that using a table scan is the best way of executing the query (as opposed to using any index). As a result, all his query plans used just table scans instead of the right indexes even when the table size increased!

</StoryTime>

Moral of the story: Caching query plans is good, but only as long as the state of database when they are compiled is representative of the average state of database during execution. If your data is changing rapidly, it is better to recompile the queries every once in a while.

So, beware of stale query plans!

Note that query plans can be cached for both parameterized and non-parameterized queries and you can run into this problem in either case. (Another insider hack: SqlCeCommand.Prepare doesn't really prepare the query plan. It just marks the command object for plan (re)compilation and the plan is compiled when SqlCeCommand.ExecuteXXX is called next time.)

2. Impression of using parameterized queries without really using them

Question: What's wrong (rather sub-optimal) with the following code:

SqlCeCommand cmd = con.CreateCommand();

cmd.CommandText = "SELECT * FROM table1 WHERE C1_DECIMAL = @p1";

cmd.Parameters.Add("@p1", SqlDbType.Decimal);

cmd.Parameters["@p1"].Value = 3.5;

SqlCeDataReader rdr = cmd.ExecuteReader();

while (rdr.Read()) { /* read the data */}

rdr.Close();

cmd.Parameters["@p1"].Value = 335.01;

rdr = cmd.ExecuteReader();

while (rdr.Read()) { /* read the data */ }

rdr.Close();

Answer: The query plan gets compiled twice, once for every ExecuteReader call!

Reason: First time the plan is compiled, the parameter's precision is 2 and scale is 1 (as inferred from its value ‘3.5'). The query plan therefore uses this precision and scale values. The only other values it can accept are those that fit within this range.

When the query is executed again, the parameter's precision is 5 and scale is 2 (as inferred from its value ‘335.01'). Since it doesn't fit in the parameter as inferred during first plan compilation, the plan is recompiled silently!

Solution: If you can anticipate the range (size, precision or scale) of the parameter values, then specify it explicitly. The plan will be generated based on the specified range then. This holds true for all character, binary and numeric types. (The flip side is that for any parameter value that does not fit into the specified range, an error will be thrown.) So the above code can be modified as follows:

SqlCeCommand cmd = con.CreateCommand();

cmd.CommandText = "SELECT * FROM [TABLE1] WHERE [C1_DECIMAL] = @p1";

cmd.Parameters.Add("@p1", SqlDbType.Decimal);

cmd.Parameters["@p1"].Precision = 10; // Playing safe by taking a larger range!

cmd.Parameters["@p1"].Scale = 5;

cmd.Parameters["@p1"].Value = 3.5;

SqlCeDataReader rdr = cmd.ExecuteReader();

while (rdr.Read()) { /* read the data */}

rdr.Close();

cmd.Parameters["@p1"].Value = 335.00;

rdr = cmd.ExecuteReader();

while (rdr.Read()){ /* read the data */ }

rdr.Close();

3. Query optimizer did not choose the best index

The query optimizer usually does a good job of choosing the index. However, it does it on a best effort basis and there can be cases where it doesn't pick the right index. In such cases, it makes sense to use index hints and outsmart the optimizer:

E.g. ...FROM [TABLE1] AS T1 JOIN [TABLE2] AS T2... can be rewritten with index hints as

...FROM [TABLE1] AS T1 WITH (INDEX(IX_On_Table1))

JOIN [TABLE2] AS T2 WITH (INDEX(IX_On_Table2))...

How do you know if your index is indeed better than the index chosen by optimizer?

Well, the easiest and brute force method is to run the query with and without an index hint and see which is better. I often use the Query Analyzer on device and SSMS on desktop to get the execution times. Another way is to generate query plans for both queries and study them for better predicate matches, index ordering etc.

4. Query optimizer did not choose the best join order

As in the case of choosing a wrong index, an optimizer can sometimes choose a wrong join order too. Again a corner case, but not impossible to run into. In such cases, you can specify the join order explicitly:

E.g. ...FROM [TABLE1] AS T1 INNER JOIN [TABLE2] AS T2 ON ... can be rewritten with a forced join order as

...FROM [TABLE1] AS T1

INNER JOIN [TABLE2] AS T2 ON ...

OPTION (FORCE ORDER)

As with any sort of query hint, you should be extra careful that you are doing the right thing. For instance, the join order chosen for a query can change between multiple runs due to several reasons. The cardinality of the join tables could have changed significantly, or the data distribution could have changed. So even though the join order that you selected at the time of deployment was optimal, it may not remain so all the time. Ordinarily the optimizer would decide the join order on fly and therefore can adjust to such changes.

Not so when the join order has been forced.

That's all for the time being.

-Pragya Agarwal

"Houston, we got some problem..." and "Houston, we got a problem..." - notice a difference?

SQLCEBLOG — Wed, 12 Dec 2007 13:18:00 GMT

So you have run into a problem - how to efficiently report this:

System configuration:

On a Desktop/Server, Run Winver from Start -> Run.
On a Pocket PC, Start -> Settings -> About
On a Smart Phone, a bit more steps - start -> Settings -> More ->About

Give us all the details you see here.

SQL CE Version:

Applies if you had installed SQL CE by various means <VS / SSMS etc.>
Search for the sqlcese*.dll, right click it and give us the version in version tab.

A detailed description of what you are trying to do:

Include all details like whether you are using Managed /Native code, single/multi-process and a sample code
A small repro of the error you are getting would be great! <In case of corrupt databases, the corrupt database>

A Dump file if the process has crashed / hung:

On a PC, install this wonderful tool - UserDump.exe from http://support.microsoft.com/kb/241215. This tool installs a control panel entry - click this and register your application's name on this. Next time you get a crash in that app, you will get a dump file in the location you specified. Neat isn't it?

In case of a hang, use the same tool above to assign a hotkey and dump the process's current state.

A word of caution, this crash dump file can be pretty big - so ensure you have enough disk space.

On a mobile device, this gets a bit trickier. If you are using Windows CE 5.0+ version, and if you are lucky enough to have an OEM vendor who has enabled Windows Error Reporting, you can get a dump. Read this wonderful article at http://windowsfordevices.com/articles/AT7568439504.html by Abraham Kcholi and Gad Meir.

For older devices <Win CE 4.2 and so on>, contact us with the program and the problem, and we will handle it case by case.

P.S: No, don't upload all the attachments on to the forums:), but keep them handy. The moment we start looking at this, we will be asking for these.

P.S.2: First post here - w00t! I am a developer in the engine team of SQL CE and I guess you will see me here time and again!

Nandri!

Subu Subramanian.

There can be hope only for a society which acts as one big family, not as many separate ones. - Anwar el Sadat

Can’t find P/Invoke DLL sqlcemeNN.dll

SQLCEBLOG — Fri, 26 Oct 2007 18:01:00 GMT

I know this is very annoying, uninformative, directionless…blah blah… error. And, kindly pardon me for blogging about this error very lately. Better late than never and here it goes.

What are the actual errors?

1) Can't find P/Invoke DLL sqlceme30.dll

2) Can't find P/Invoke DLL sqlceme35.dll

3) Can't find P/Invoke DLL sqlceme40.dll

What exactly this error means?

When a managed assembly (In our case, System.Data.SqlServerCe.dll) is trying to P/Invoke a method on to a native DLL (In our case, sqlcemeNN.dll; where NN stands for version of product 30, 35 …etc), system has failed to find the DLL to load and invoke the method.

When do we get this error?

We get this error when system cannot find the DLL in the system path, or current process executable path.

How can one land in this error? What are the probable workarounds or fixes?

There are multiple cases and some of the well known ones are given below:

1) Prior to .NET CF 2.0 SP2, there is no concept of GAC on storage card. And, if you have installed SQL CE Cab on storage card with .NET CF 2.0 RTM/SP1 on device, our native DLLs end up on storage card and the GAC on the main memory. Hence, managed assembly will fail when P/Invoking above method

a. Please use .NET CF SP2 and above

b. Please install the cabs on main memory

c. Please move to SQL CE 3.0 SP2/3.1 and above

2) You are developing the application for smart devices (Windows CE OS based) and using Visual Studio Auto Deployment (F5) feature. And, VS has failed to map the System.Data.SqlServerCe.dll to the right set of cabs to install and just deployed the System.Data.SqlServerCe.dll alone (Note: No error is thrown). In this case, the native DLLs are not deployed.

a. Fix the auto-deployment issues (Don’t ask me how L)

b. Remove and add the reference to System.Data.SqlServerCe. This is because, VS IDE stores assembly identity in the project file. Since we have changed the assembly version in SQL CE v3.5 SP1, removing and adding updates the solution to host the right assembly version

c. Manually copy and install the SQL CE Cabs (all the 3 cabs). They are located under:

%VisualStudioInstallRoot%\SmartDevices\SDK\SQL Server\Mobile\v3.0\<platform>\<processor>

%ProgramFiles%\Microsoft SQL Server Compact Edition\<version>\Devices\<platform>\<processor>

3) System has failed to load the sqlcemeNN.dll. To find more details on why system might have failed to load a module is discussed in my previous blog post.

4) If your machine is a 64-bit box, you might have been got trapped into default target platform 'Any CPU' trap, please set the target platform as 'x86'. Need more details, please visit ErikEJ's blog post.

5) In all other cases, please move to SQL CE 3.0 SP2/3.1 and above. If possible make sure HKLM\Software\Microsoft\Microsoft SQL Server Compact Edition\<Version>\NativeDir registry points to the directory where our native DLLs are installed. Please consider the WoW registry if running in WoW mode.

Thanks,

Laxmi Narsimha Rao ORUGANTI

[Update: Edited Actual Errors section to see if it helps in catching Live/Google's eye]

[Update: Added 64-bit box story and also a reference to ErikEJ's blog post]

Troubleshooting: Can’t load sqlce dll

SQLCEBLOG — Fri, 26 Oct 2007 17:01:00 GMT

SQL Server CE/Comapct uses Windows API LoadLibrary (PlatformBuilder or WinCE or Win32) to load the DLLs. When LoadLibrary fails to load any SQL CE dll, we throw the error “Can’t load sqlce dll”. Now, let’s discuss more on why LoadLibrary can fail.

1) Virtual Memory is too low to load the dll

2) Dependant DLLs are missing

3) Windows CE LoadLibrary has done something strange

Regarding point (2): Please run depends.exe on our DLLs and make sure your image has got all the required dependant DLLS. Note that, SQL Server CE stack depends on OLEAUTO.DLL, OLE.DLL. Some of the custom built images might not have selected Platform Builder catalog for COM Support and hence system fails to load the module.

Regarding point (1) and (3): Please read the KB Article 326163 completely as I am going to highlight few things from that article.

<Extract>

When a DLL is loaded in one process, Windows CE reserves that address space in every process address space. Multiple processes that use the same DLL share it at the same relative address in every process. If your application does not use the same DLL, it cannot use the memory that is reserved for that DLL. In other words, Windows CE does not map a RAM-based DLL at an address where another process maps another DLL. For example, if Process A loads DLL X at address 0x00970000, Windows CE does not map DLL Y in the Process B address space at 0x00970000. Instead, Windows CE seeks the next lower address that is available, depending on the size of DLL Y. So if DLL Y is in the size range of 128 KB, Windows CE selects 0x00950000 if that address is available for Process B. Because of the way that Windows CE allows processes to share a common DLL, Windows CE does not permit two different processes to load two different DLLs at the same relative address of each process.

</Extract>

Which means if there are many DLLs loaded by different processes; and your process is last to load your process LoadLibrary might fail as lot of address space is reserved.

The workarounds proposed from the article are:

<Extract>

If you determine that your application cannot load a DLL because of a lack of address space for the DLL, consider the following workarounds:

1.	If your application is implemented in Microsoft C or Microsoft C ++, or if your eMbedded Visual Basic application uses custom DLLs, determine whether you use the VirtualAlloc function with the MEM_TOP_DOWN flag. When you use this flag, you allocate memory as high as possible, and you can cause DLLs to not load. VirtualAlloc must not use this flag.
2.	If your application uses a lot of small custom DLLs, consolidate the code in one or two DLLs. The minimum address space that a DLL consumes is 64 KB. Therefore, for example, if you design your application so that thirty DLLs all fall between 8 and 10 KB, you waste 1,620 KB of address space.
3.	Break the application down into more than one process. Use one process to load one set of DLLs and then use another to load a different set of DLLs. (Based on the application design, this may not be practical. If both processes must run simultaneously, then it does not help to use two separate processes.)
4.	Load all your essential DLLs when you first load the application. If possible, keep the DLLs loaded. After you make this change in your application, watch to see if memory allocations or other processes do not work as a result. If they do, you must redesign your application to minimize DLL or memory.
5.	Redesign the application to use less memory overall. Use only essential DLLs and then unload them if you do not require them. Minimize heap usage, as this impacts how many DLLs can load. Note that references to ActiveX objects do not unload when you set the object variable to Nothing.

</Extract >

The work around people could easily try out is (4) and it has worked for few of our customers. The other thing is to try unloading the unused modules using CoFreeUnusedLibraries (Win32 or WinCE) API if COM based applications have run.

Kruthagnyathalu / Dhanyavadamulu / Thanks,

Laxmi Narsimha Rao ORUGANTI