Starting my blog

I’ve decided to go ahead and start a blog. I often run across things that I would like to blog both for other’s sake and for future reference by myself.

After doing initial research into something, it’s often very time consuming if not impossible to find all of the resources again should you run into the same problem later.

So, this is my first blog entry to kick off my new blog. This blog will contain technical research, resources, ideas and many other things. Anyone wanting to comment on any of this is welcome. I look forward to hearing from anyone.

6 thoughts on “Starting my blog

    1. I actually had two problems. The main problem was that I was receiving a linked server null error on importing Excel files using OpenDataSource. I could import once, but it would require restarting the SQL Server service before it could import again. So, it was import, restart, import, restart, … which of course is not a good thing. So, I’ve been trying to hunt down the problem and fix.

      The forum post you referenced is a possible fix that I found for this issue. According to the article I mentioned in the post, this can happen if the account the SQL Server service is running under doesn’t have access to the temp folder specified in the temp or tmp environment variables.

      So, I needed to create an account for the SQL Server service to run as. The problem is that our corporate security standards don’t allow service accounts to have interactive logon privileges, meaning I can’t logon to the server with the account. This combined with the fact that the “stock” temp location is generally inside of a C:\Documents and Settings\UserName\ and is only created upon first logging in as a user, meant I still wouldn’t be able to have access to the temp folder.

      I was able to get around this by simply moving the temp folder to the root of the drive, changing the environment variable and restarting the services. However, I still haven’t fixed the main issue. I have researched this for almost a year now and have tried everything I can possibly think of including file system traces, resetting permissions, SQL traces, service account changes, pouring through event logs, monitoring file system-registry-processes-services-etc. events, tracing the .net app that uploads the files and so much more. This issue has been a major issue for me, which I still have yet to resolve.

      If you are experiencing this issue and do ever find out the solution, I would greatly appreciate a comment letting me know what you did! You can see some of my posts about this issue since I have the RSS feed from my MSDN Forum posts to the right of this blog.

      1. Yes, have new info. The sql acct uses in process and windows acct within the same domian (not counting trusted domain) uses out of sql engine process to execute openrowset. If your virtual memory (memory-to-leave) area is too small, it will result with those errors. By default, the memory-to-leave is about 256mb. The memory-to-leave is used by extended dll, sqlclr, oledb, and openrowset. Use a -g at startup option for the sql engine to increase the size to say 512mb, e.g. -g512. My issues has not reoccur. I have a feeling that Jet.4 is leaking memory. Althought its replacement by Microsoft is ACE.12.0 which has a bigger footprint than Jet.4, it is recommended to switch to Microsoft.ACE.12.0 and increase your memory-to-leave to 512mb.

  1. I ran the query specified in this article and found that it shows a little over 26MB free and 79MB available. I’m sure that’s not nearly enough. However, I’m also a little hesitant to just increase the size since it sounds like allocating more space to MemToLeave removes it from the BPool and can cause performance issues and possibly even not allowing the SQL Server service to start.

    I have a total of 6GB RAM on the SQL Server and am running AWE so SQL will make use of this. On a fresh reboot the server is already consuming about 4.5GB of memory (with SQL running). Below are some results of the DBCC MEMORYSTATUS command.

    Memory Manager
    VM Reserved – 1680664
    VM Committed – 71684
    AWE Allocated – 0
    Reserved Memory – 1024
    Reserved Memory In Use – 0

    I really appreciate your help with this. If this is the issue and resolves the problem, I will be incredibly grateful!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s