This is addressed in Microsoft KB321363: When you start Microsoft SQL Server, SQL Server memory usage may continue to steadily increase and not decrease, even when activity on the server is low. Additionally, the Task Manager and the Performance Monitor may show that the physical memory that is available on the computer steadily decreases until the available memory is between 4 MB and 10 MB. This behavior alone does not indicate a memory leak. This behavior is typical and is an intended behavior of the SQL Server buffer pool. By default, SQL Server dynamically grows and shrinks the size of its buffer pool (cache), depending on the physical memory load that the operating system reports. As long as sufficient memory (between 4 MB and 10 MB) is available to prevent paging, the SQL Server buffer pool will continue to grow. As other processes on the same computer as SQL Server allocate memory, the SQL Server buffer manager will release memory as needed. SQL Server can free and obtain several megabytes of memory each second. This allows for SQL Server to quickly adjust to memory allocation changes. That article will give some further links on how to adjust memory, but in general it's best to leave it alone. I believe SQL Express 2005 is capped at ~1GB usage anyway.

Hi Richard, Unfortunately it doesn't look like the exact error is being reported, but it definitely happening when the database schema is being initialized. Based on the error code, it looks like it's happening at the database driver level has something to do with updating the database schema. Perhaps there's an error connecting to the database, or something? Your best bet might be to tryagain, or use try the manual install process for the database.

Wow! Talk about agile, thank you for the quick turn around.

Hi Tero, The MySQL Database Provider is just passing the script as a command to the database. I did a quick search, and it looks like it might be configuration (connection string) related. Does your connection string have "Allow User Variables=True" in it? http://dev.mysql.com/doc/refman/5.0/en/connector-net-connection-options.html Best, Steve

Good question – we’ll have to fix this in our documentation. The BuildMasterUser_Role is for the BuildMaster Application (WebApp/Service) talking to the BuildMaster Database – doesn’t have really anything to do with deploying to databases. The database deployment bits of BuildMaster need only the permissions that the scripts need to run. You set up the database credentials in a your connection string (or, if you’re using integrated authentication, the service account) – so it’s really up to you. We generally recommend giving db_owner against the target database, since your scripts will generally do a bunch of things like create, alter, etc. But that’s up to you. The script will just error out if permissions aren’t there.

The connection string format is just a typical database connection string. You can follow the examples listed here: http://connectionstrings.com/ Specifying init as "yes" will initialize the database if it hasn't already been initialized. You'll need to specify this if you're running the changescripter tool against a DB for the first time.

This has been updated; Oracle Extension 3.1 now supports multiple commands per script. You can update this from within BuildMaster

The Database Connections module is designed to segregate connection strings in this exact manner; this way, only certain privileged users can use the database connection their privileges allow. In this case, it might make sense to build a custom Database Provider that's based off of the SQL Server one. This is pretty easy, and several users have done this. Please contact support, and we will send the source code for this.

Yes, deleting and readding the action step fixed this bug. I should have tried that, I suppose. Thanks! Matthew

When you share/link action groups, you may select a "Default Server" for the actions, which means you can link them across environments and still have the actions run on different servers (just select the local BuildMaster server for the actions, that will be overridden by the selected default server of the group). If you choose a separate build server for your actions instead, that will take precendence over the default server unless the build server is the same as the BuildMaster server; if that's the case you can just put those actions in a separate group. As for the database selection, we could update that action to allow selection via a variable or have a default option that chooses the DB based on the environment it's in.

Thanks Steve. That was enough for us to implement a custom action, and the action were pretty easy to implement based on the source code that you provided. Appreciate the prompt response!

Thanks for the confirmation. I just tested this technique, and it worked really well, actually. I'm going to use the following naming convention: DEV SQL Server (the actual DEV database) TEST to DEV SQL Server (the TEST database available to the DEV BuildMaster environment) PROD to DEV SQL Server (the PROD database available to the DEV BuildMaster environment) I was concerned that BuildMaster would want to re-initialize the database, but it didn't. In fact, during the next build in DEV, BuildMaster correctly backed up my PROD db and restored to DEV and then determined that my SQL Change Script had never been run (since the BuildMaster execution table is also restored). This is how I expect and want it to behave. Thanks again for the VERY FAST response! Matthew

Hi Oleg, The problem is that the database stores some of this information as VARCHAR instead of NVARCHAR. SQL Server converts cyrillic (and other non-Latin) characters to ???. Unfortunately, there is no quick fix; the appropriate columns (and stored procs, etc) must be changed to NVARCHAR. But we do have this planned for 3.2, which isn't too far away. Best, Steve

The "Execute Database Scripts" action executes all the scripts in the specified source directory (and all subdirectories of that directory) on every execution. The only scripts that are run once and only once are the Change Scripts via the "Execute Database Change Scripts" action. Can you verify that: the action is referencing the correct provider and instance the action is running the correct server if applicable, previous actions are putting the .sql files in the correct source path on the correct server the source directory of the "Execute Database Scripts" action has the files you expect in it

The user that connects to SQL Server needs to be granted the BuildMasterUser_Role; this role is created as part of the database creation. No additional roles or access is needed.