SQL Username hard coded in migration

udotdevelopment / ATSPM

Automated Traffic Signal Performance Measures (ATSPM) are a series of visual aids that display the high-resolution data from signal controllers. They are a valuable asset management tool, aiding personnel in the control of both signal hardware and signal timing and coordination. They allow analysis of data collected 24 hours a day, 7 days a week, improving the accuracy, flexibility, and performance of signal equipment and the system as a whole. ATSPM are used to optimize mobility, manage traffic signal timing and maintenance, reduce congestion, save fuel costs and improve safety.

Apache License 2.0

72 stars 40 forks source link

SQL Username hard coded in migration #52

Open ian-cameron opened 5 years ago

ian-cameron commented 5 years ago

This SQL Server Agent Job looks useful, however it is hard coded to be owned by user 'SPM', so if your server doesn't have a user name 'SPM' it will make migrations fail in a non-obvious way with an error like

  System.Data.SqlClient.SqlException: The specified '@owner_login_name' is invalid (valid values are returned by sp_helplogins [excluding Windows NT groups]).

The workaround is create a user name SPM (you don't even have to change your connection string in the config file), or change this line in the code to match the username you're using in your connection string.

Hope this saves someone time.

https://github.com/udotdevelopment/ATSPM/blob/87ab539edd92885d6a3c9fdce4a387aace96ab51/MOE.Common/Migrations/ScheduleReclaimFileSpaceFirstFriday.sql#L27

udotdevelopment commented 5 years ago

We have had some issues with this script that we are continuing to refine. There are some assumptions being made. You are correct that the user is one of those. Another is that you are using month partitions on your speed and controller_event_logs tables. We were hoping that those who may be interested in using it could take it and modify it accordingly. We will try to put together a document to help with this in a future release.

dbrandesky commented 4 years ago

This fixed my issue #63! I spent like 3 days trying to figure this out. FWIW, I did also need to give the 'atspm' user I created sysadmin privileges to get around the initial issue I found (not able to SELECT or EXECUTE in the msdb database).