Hi, I'm sorry I don't seem to have got a notification email when you replied, so I only just saw this. I just tried 5.2.29 and it works perfectly. Many thanks!

Hi Bohdan, For the feed migration please refer to this: https://inedo.com/support/kb/1168/migrating-a-proget-feed As far as Users/Api Keys.. are you using a Built-In user directory only? Thanks, Jason

Thanks. That solved it.

The SQL server and the application are both on server 'Production' and the application is successfully retrieving data from the SQL server. The connection string used in the application configuration is the same connection string being used in the SQL connection in Buildmaster. It is using a SQL account, so not integrated. Here is a redacted connection string: - Data Source=*************;Initial Catalog=*************;User Id=*************;Password=*************;MultipleActiveResultSets=true;

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.

Proget non hub installer on French W2016 Core server with remote SQL db is working fine The pb exist with BuildMaster Hedgehog but not with Otter Best regards Philippe

It's hard to say, because we don't have enough information. The "code" you shared looks like it's part of a PowerShell script, or maybe it's a cmd script, which maybe they're executing from BuildMaster? Or they could be executing the process directly? Where does $targetInstances and $targetDatabase come from? if they're just running a PowerShell script, then I guess they should just edit that powershell script as you suggested? Can you just ask for the deployment plan? Unless it's v4 or earlier, it will be in OtterScript (a text file), and once you see it, it should be fairly clear how to change it.

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.

ProGet supports any version of SQL Server starting with 2008.

You can just back-up the database, and then restore it in the new SQL Server.

We don't support doing this sort of tweaking on the ProGet database; it might work, but we don't test it so I can't say.

You'll need to run bmdbupdate.exe. It doesn't need to be run on the database server itself; the user that runs it must have dbo permissions to the proget database.

That's the error from the SCM, but the .NET error is also logged. You may want to try running the service interactively in this case, then you can see the error message and identify what's wrong with the db connection.

As of v5.6, the "SQL Change Scripts" feature is designed with these principles in mind: Database Changes Done Right. Run once and only once Impossible to be “un-run In order to accomplish this, a metadata table is created in the database (__BuildMasterDbSchemaChanges2) to track which change scripts have already been run. Before running a script, this table is queried. Regarding "resetting" the idea that a script is run, the best bet is to delete and re-add it from BuildMaster. You can also restore that particular database.

Regarding the database migration, we don't have an export/import function.. but you can just recreate the feed and use the bulk import path for your exisitng packages.

Just discovered Kevin's answer here which should work: http://inedo.com/support/questions/4058#inline-post-5062

In this case, you are pointing PRoGet to a SQL Server on a different machine. You will need to either use a different connection string (name/[assword), run proget service/web under a domain account and continue to use integrated auth, or allow connections from that machine in SQL Server (not recommended).

What you described should work; the connection should be proxied through the agent server you selected. however, I see you also submitted a ticket... so we'll review via that!

I suspect the two messages are unrelated... but unfortunately it's really hard to know what would cause the first problem. 99% of the time, especially over long-running things like this, it's a result of problematic network connections. The new Inedo Agents (available in v5) are a bit more resilient to this.

Please refer to the High-level Architecture Diagram to see the components of a ProGet installation. The Database is a SQL Server database. The Web and Indexing Nodes are both .NET application that interact with the database using the standard SqlClient API. The connection string you specify in the configuration file is assigned to the ConnectionString property of that API. All of this is very standard, but it's very likely that your DBA/Network Admins configured the SQL Server you wanted to use in such a way that a simple/intuitive connection string was not sufficient. Maybe they used a special port, security, etc.; they would be much better suited to answer your question about why it's so complicated :) Also, please note that the ProGet Installer will create/update the tables and object in the database. ProGet itself does not modify (nor have the privileges to modify by default) the database structure. If you wish to install the database component outside of the installer, then you will need to follow the Manual Installation Instructions.