Asp.net mvc 在Azure Web App设置（而不是Web.config）中存储ConnectionString后获取失败的连接

在圣诞节期间，我将我们的web应用程序（MVC、EF6、SQL Azure）更改为使用Azure的web应用程序属性设置中的connectionstring设置，而不是在web.config中。这有两个目的：

1） 更安全

2） 帮助防止将应用程序意外重新写入错误的数据库

自从这样做以来，我发现我们40%的连接都失败了。现在，这可能与Azure问题同时出现，因为在我使用的另一台SQL Azure服务器上执行此操作时，我无法重复此操作

我在Azure中输入的ConnectionString数据是：

应用程序

数据源=tcp:live1 server.database.windows.net，1433；初始目录=实时数据库；用户ID=user@live1-服务器；密码=12345

EntitiesCS

元数据=res://AppNamespace/app.csdl|res://AppNamespace/app.ssdl|res://AppNamespace/app.msl;provider=System.Data.SqlClient；提供者连接字符串=“数据源=tcp:live1 server.database.windows.net，1433；初始目录=Live DB；用户ID=user@live1-服务器；密码=12345“

埃尔玛

数据源=tcp:live2 server.database.windows.net，1433；初始目录=ElmahDB；用户ID=user@live2-server.database.windows.net；密码=9999

出于明显的安全原因，我更改了相关的详细信息

因此，我的问题是：

1） 是否有人在使用Azure存储Web应用程序的连接字符串时遇到连接失败的问题

2） 我的细节看起来正确吗。我假设他们会这样做，因为应用程序会连接，但不是一直连接

这个问题可能是偶然发生的，但是从23日到现在Azure DB服务器上出现“连接失败”问题似乎是一个很长的时间，如果它是由Azure基础设施问题引起的

提前谢谢

编辑

我通过以下方式分析了事件日志：

SELECT      
        [Date From] = EL.[start_time],
        [Date To] = EL.[end_time],
        [Database Name] = EL.[database_name],
        [Event Type] = EL.[event_type],
        [Event Sub Type] = EL.[event_subtype_desc],
        [Description] = EL.[description],
        EL.event_count,
        [Additional Data] = EL.additional_data
        FROM sys.event_log EL
        WHERE EL.event_type != 'connection_successful'
        AND EL.event_subtype_desc != 'idle_connection_timeout'
        ORDER BY [Date From] DESC

---

我注意到我在这里遇到了很多“登录用户失败”的错误，虽然我的web应用程序似乎工作正常，但速度较慢。这些错误是在我使用Azure门户更改SQL Azure密码后开始的。我无法从“事件日志”中判断是什么导致了这些故障。所有预定的流程都可以正常工作，不管怎样，这些只是一夜之间的事情。我每隔5分钟左右就会收到这些错误。新密码的强度要大得多，即20个字符和随机密码。这是否会导致SQL Azure出现问题。这种错误的间歇性性质很奇怪。

这听起来确实是巧合。要么连接字符串不好，所有操作都应该失败；要么连接字符串很好，无论您是在web.config中硬编码还是使用Azure设置，它的工作方式都应该相同

---

将其放入Azure设置会导致在运行时将其注入.NET配置系统。在这一点上，这两种情况基本上是无法区分的。

使用MySQL数据库托管在Azure Web应用程序中的PHP应用程序遇到了类似的问题。将连接字符串更改为指向其他数据库并删除以前使用的数据库后，备份开始失败，错误为无法连接到数据库。错误消息表明它正在使用旧数据库的连接字符串。

---

备份的“重置配置”似乎起了作用

谢谢你的回复。所以基本上你是说，把它放在Azure中应该不会影响它。我相信这是最好的做法。是的，这是我们的建议。我只是指它对你们的失败并没有影响。我怀疑如果你把它放回web.config，你会继续看到同样的失败。我已经尝试并监控了我的QA SQL Azure服务器上的DB活动，这似乎很好。所以我想知道我的LIVE DB服务器是否有问题。因此，我已经创建了另一个sqlazure服务器，我将在新的DB服务器上导入问题DB实例的副本，并查看问题是否继续存在。再次感谢。我认为对于这个问题，我们需要尽可能地回答它是否在Azure设置vs.web.config中是一个因素。一旦我们确认它不是，如果你有连接字符串问题，不管它是以何种方式存储的，你应该问一个单独的问题，集中在这一点上，省去关于它如何存储的整个部分。公正的评论，谢谢你的帮助。我不认为有什么不同，我认为还有另一个原因。感谢您的帮助您没有指定错误。但是您可以查看

sys.event\u log

DMV，通过将时间戳与失败的时间戳关联，了解失败的原因错误为“用户登录失败”。我真的不理解你的评论“将时间戳与失败的时间戳相关联”。谢谢你迄今为止的帮助。顺便说一句，我想我可能跟踪了一个突然的想法，这看起来是正确的。基本上，我有一个指向同一个数据库的部署槽，但未使用，但有一个应用程序设置“始终打开”设置为“打开”，这会导致Azure ping该站点，从而导致这些尝试的DB访问。我停止了此插槽，事件日志到目前为止看起来不错。我的意思是，根据我的理解，将您的登录失败时间与DMVeventlog存储数据的时间戳关联14天向下滚动到事件聚合部分：