MDAC support on Windows Operating System

MDAC packages ADO, OLEDB and ODBC interfaces together in one installer. It comes pre-installed on Windows XP, Windows 2003 server and Windows VISTA (there it is called WDAC i.e. Windows Data Access Components). Here are some links to Microsoft website regarding MDAC support on Windows operating system.
http://support.microsoft.com/kb/231943
http://msdn.microsoft.com/en-us/library/ms810805.aspx

MS access memory leak

Jet database uses in-memory cache which is set to infinite by default. If you are using Jet database in any of your process then make sure you set cache size to something definite otherwise your process will just continue consuming memory like anything. The cache size of Jet database just grows in size and there is no ways to reduce it (event connection release won't help in this case). Microsoft documentation says that you can set it through registry also. I tried to set it through registy but it did not get reflected. So setting it through code is the only option. Below are some useful links on this matter

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

http://msdn2.microsoft.com/en-us/library/aa140022(office.10).aspx#adoproperties_connectioncollection

MS Access database insert succeeds only if date is entered after 12th of every month

There was an issue of entering a record in a MS access table having date field. The issue comes only if date is less than 12th of month. For all other date, insertion was working fine. Also insertion was successful if month and day parts of a date are same.

The issue was related to how MS Access database stores date internally. By default it stores date in US/English format (i.e. mmddyy). We had used ADO for updating database. The system date was converted to variant date before insertion. This way we did not had any control on the formatting of the date.

Instead we changed the query to specify date using date formatter (#mm/dd/yyyy#) while performing insert or update operations. This method ensured that the date is always specified in mmddyyyy format no matter what is the locale of application or OS.

MSISetProperty API fails

Today I ran into a problem where very first MSISetProperty API call from our custom dll failed. Some search on Google led me to the following solution.

MSISetProperty internally make calls to some COM component. To execute any COM call on a machine, INTERACTIVE and SYSTEM accounts should be added to the default access list for all COM components. So the COM objects which do not use any specific custom security setting, uses these default security settings.

This default security setting was not enabled on the problem machine and that’s why the MSISetProperty call was failing. The problem is solved after putting in access permission for these accounts

DCOM permissions are not set for some accounts on non-english OS

I ran into this problem on non-english OS which was reported by one of our customers. After digging into it, I found that certain DCOM permissions (e.g. 'Launch and Activate', 'Access permission') were given to INTERACTIVE and NETWORK_SERVICE accounts. The account name was hardcoded in english. On non-english OS, these names are localized in the OS language and so the permission granting code was failing.
There are SDDL strings assigned to each account / group created by operting system. These strings can be found in sddl.h header file. These strings should be used for refering to the account name rather than the name itself. This saves from any localization issues as these strings are defined for accounts and not for there names.