Thank you very much for your precision. I realy appreciate it. I personaly work with non conterize Postgres database in order to avoid data corruption issue; but I understand your make this decision. Hava a good day, Mathieu HOFERT

Apologies - I broke that endpoint earlier ironically by accidentally disabling logging :( It should work now; I also note that you can request a key at https://my.inedo.com and manually enter it.

Hi Tod Thanks for the fast response. Since i am not relying on the statistics of Proget i have solved the issue with a bit of work. Created new feed that uses new standards setup custom feedpath and droppackage path for bulk import on the server i located that packages on the filesystem and dumped into the appropiate bulk import folder. wait a minute or two and the new feed has all the packages. Rename feeds so the new one has the name of the old deprecated. It is a workaround but it works but again - you loose statistics. Symbols and Source seem to survive :-D

This would require a custom operation to capture this text. You could also use a tool like sqlcmd.exe to output the result to the textfile.

This is a false positive; unfortunately we seem to be the target of many of them :( See http://inedo.com/support/kb/1113/anti-malware-false-positives-code-signing-and-safety-of-inedo-products Please report the false positive, because some of the virus total companies will not let us do it, only their customers.

There isn't, although we do have an open item -- BM-3042 -- for it.

Thanks, I was able to download the Oracle extension and modify it to look for a custom statement delimiter for testing purposes. A few tests seem to check out fine so I'm able to deploy package updates this way. This means I have to customize my deploy scripts but this may be an acceptable tradeoff for now. I've made my statement separator tokens comment sequences (i.e. "--$$") so that the script can still run in sql*plus.

Not currently, it's just per application level right now. We will definitely consider adding that in a 5.x release!

You do have to check the "remove the database and packages" options in the uninstaller, so if you did that it should have done just that, unless some error occurred or something like that. It's hard to say why things weren't removed in this case, but it's hopefully easy enough to manually remove if it didn't work. We'd rather there be a bug in not removing, instead of a bug in removing when you didn't want it to :)

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 likely an incorrect error that's being reported; next time you see this, 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.

I'm not sure what you mean, are you saying all the servers on the Server Overview page are shown as "checking"? The best bet is to restart the BuildMaster service and web application if it's "stuck", but otherwise, upgrading BuildMaster should also resolve that since it no longer pulls the status directly from the DB as of v4.1

Hi Wajeeh, It looks like there is definitely something wrong with your database; probably, the stored procedures are being created under different schema (i.e. not dbo). If this is the case, You can rectify this by dropping the database, and then running the bmdbupdate.exe tool from the manual install packages... but it's probably easier to uninstall, drop the BuildMaster database, and then reinstall.

Interestingly enough, disabling connection pooling for Buildmaster seems to have solved our issues. It's been five days and there hasn't been a single error in the event logs or Buildmaster itself. In app_appSettings.config we now have our connection string setting looking like this: <add key="Core.DbConnectionString" value="Data Source=localhost; Initial Catalog=BuildMaster; Integrated Security=SSPI;Pooling=no" /> Could this possibly be caused by a connection in Buildmaster not being disposed properly such that when it is pulled back out of the pool, it's in a broken state?

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.

Can you be more specific? What do you mean by, "entire database"? The built-in Change Scripts feature will allow you to script an entire database if needed, and ensure change scripts get run once and only once.

NOTE : BuildMaster has Retention Policies which are strongly recommended, rather than manually purging data That being said, you can use the same strategy to delete from that table that you used for log entries: BuildMaster 4.2 and earlier: SELECT TOP 100 * FROM BuildExecution_PlanActionVariableValues --DELETE BuildExecution_PlanActionVariableValues WHERE BuildExecution_PlanAction_Id IN (SELECT BuildExecution_PlanAction_Id FROM BuildExecution_PlanActions BEPA INNER JOIN BuildExecutions BE ON BE.Execution_Id = BEPA.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected') BuildMaster 4.3 through 4.9: SELECT TOP 100 * FROM BuildExecution_ActionGroupActionVariableValues --DELETE BuildExecution_ActionGroupActionVariableValues WHERE BuildExecution_ActionGroupAction_Id IN (SELECT BuildExecution_ActionGroupAction_Id FROM BuildExecution_ActionGroupActions BEAGA INNER JOIN BuildExecution_DeploymentPlans BDP ON BEAGA.BuildExecution_DeploymentPlan_Id = BDP.BuildExecution_DeploymentPlan_Id INNER JOIN BuildExecutions BE ON BE.Execution_Id = BDP.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected')

Thanks Philipp, we've identified some additional performance issues as well and will plan to release a maintence ProGet release to fix this .. ideally today.

Thanks Tod, I have run your query and it deleted most of the rows out of the log table. However, Buildmaster is still timing out due to slow database performance. Are there any other tables we can reduce in size. Also we are looking to upgrade to SQL Server as soon as possible.

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.