I updated the default schema on the security group I was using to dbo and I was able to run a successful install. Thank you!

When the new SQL Server is installed, simply backup and restore the existing ProGet database to the new server, then update the connection strings in the .config files located in the Service and WebApp install directories so that they point to the new server.

I bumped into this issue as well. It turns out if you wanna use existing local SQL server, you need to add an account "NT AUTHORITY\NETWORK SERVICE" to your SQL database. To be clear, this account is added to ProGet database during installation but it didn't mark as "Public" in server role.

A bit late in the game for an answer, but I thought I would add my two cents: Tod is 100% correct, you do not want to use variables within Buildmaster for this, but you do not need to go the length of over-managing either. To resolve this issue: Passwords: Resolve this with the credentials for the database. Database name differences: Have your DBA create a Synonym across the board. For example, if your app is named "DirtyHarry" and on DBDEV is called "RevolverDB" and PRODDEV is called "MagnumDB" just create a synonym "DirtyHarryDB" on both servers, resolving to the actual DB name. Then in all your change scripts use DirtyHarryDB... or just set a synonym on DEV to be the same as PROD DB name or vice-versa. There are quite a few ways you can resolve issues like this, but it is always better to be genericized. We have the same in that we utilize snapshots in DEV that can be in any database location, but in production they are referenced to linked servers. -Kevin

This is fairly easy to reproduce -- just turn off the SQL Server. As to why it's happening, that's hard to say... perhaps it's being rebooted? Or you have network connectivity issues? If this is happening, I wouldn't disable pooling --- instead, just try to restart the web app by going to, Admin > All Settings > Save. This will re-establish a connection to the service on restart, and should clear this error. Another thing you may want to do, is to configure the service to crash on database errors; then set auto-recovery. You can do this by setting a value in your service's application configuration file, "CrashOnDbFailure" to "True", and changing the recovery settings in Windows.

hi, I'm not sure I understand the question? But, you can set up multiple database conenctions in your application, and pick the ones you want to use... either directly or with a variable.

This will be the simplest resolution. First, upgrade the database instance to SQL Express 2008 or 2014; this will increase your limit to 10GB. Just download and run the installer from Microsoft, and instruct it to upgrade the instance. Then, upgrade to BuildMaster 4.8, which will have retention policies that allow you to delete/purge execution logs (which are taking a lot of space).

Thanks. Removing \SQLEXPRESS fixed it. -Michael

You can just back-up the database, restore it on the new server, and edit the connection strings in the appSettings config files for the web and service.

The installed express database by default is at localhost\PROGET (i.e. machine_name\instance_name). To switch, simply backup and restore the database into the new instance, and update the connection string in web_appSettings.config under the web installation path, and ProGet.Service.exe.config under the service install path.

It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade. Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.

It is... but in this case it seems the error is that an empty value is attempted to be added; it's hard to know exactly where that value is coming from by just seeing the error message unfortunately... In BuildMaster 4.1 and earlier, empty variable values are not allowed. This will change in 4.2, along with some other improvements.

Wanted to follow up on this issue and thank you for the response. We upgraded from 4.1.5 to 4.1.6 and I reran a script that should have failed and it did indeed throw an error. SQL Server Extension was upgraded to 4.1.3.0 and the expected error is thrown. Thanks again. Source and Target directory same; splitting. AgentBasedAction Initialization Complete: Temp Directory: C:\Program Files\BuildMasterAgent_AGTTMP_A4_S0\TMP Source Directory: C:\Program Files\BuildMasterAgent_AGTTMP_A4_S0\SRC Target Directory: C:\Program Files\BuildMasterAgent_AGTTMP_A4_S0\WRK Server: XXXXXXXXXXXXX (Id: 2) Initializing action... Initialization complete. Executing... DB Version: 1 Current Version: 1 Total Scripts in BuildMaster: 8 Scripts Reported Run by Target DB: 10 Determining scripts that need to be run... Scripts to run: 1 Executing FailFailFail The script "FailFailFail" execution failed. SQL Error: Cannot find the object "dbo.KSJHFKSHFKJSSKFLSJKDF" because it does not exist or you do not have permissions. Execution Complete. Execution complete. Finalizing... Target directory unused; joining with source. Finalization complete.

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.