在使用授权之前,我遇到了一些问题,因此我得到了全新的东西-新计算机,新操作系统,VS的全新安装,Azure上新资源组中的新应用程序和数据库。整个沙邦。
我可以确认可以登录到Azure DB,如下图所示。
我可以看到数据库,表,用户等。
问题是,尽管它在本地运行(使用为我自动提供的默认连接字符串),但在Azure中却无法很好地运行(尽管我正在使用从那里发布的文件)。它说了一些关于找不到文件的事情,根据这个答案,我需要更改连接字符串。
更改后,出现以下错误。请注意,防火墙已打开,并且在运行应用程序代码时可以访问数据库。我认为自动配置身份验证部分时出了点问题。不过,我对如何解决它没有想法。
[SqlException(0x80131904):用户'Chamster'登录失败。该会话的跟踪ID已分配为“ 09121235-87f3-4a92-a371-50bc475306ca”。需要帮助时,将此跟踪ID提供给客户支持。]
我正在使用的连接字符串是这个。
Server=tcp:f8goq0bvq7.database.windows.net,1433;
Database=Squicker;
User ID=Chamster@f8goq0bvq7;
Password=Abc123();
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=10;
这个问题困扰了我一阵子,我将在两天之内解决这个问题。任何建议都将受到赞赏。
我相信我已经解决了这个奇怪的问题。似乎我正在使用的用户尽管在所有麻烦中都被管理员使用,但在连接字符串中使用并尝试创建表时,这种用户并没有被识别为管理员(第一次注册时就是这种情况)。
我的解决方案是创建两个登录名-一个具有db_owner角色的登录名和一个具有db_datareader和db_datawriter的登录名。首先,我在连接字符串中使用了提升的用户,并注册了一个用户。如下所示在数据库中创建了表。
然后,尽管可以继续以管理员身份运行,但我意识到我们应该尝试降级的用户和tada !,它运行良好。桌子摆好后,整个共享活动就会按预期进行。
完全可以肯定的是,我从数据库中删除了表,就在那里-和以前一样。当我更改为提升权限的用户时,表已还原,使我可以恢复到降级的表。
我还尝试删除表,确认问题再次出现,然后手动创建表。那也行!因此,基本上,导致这一切的唯一陷阱是原来的管理员,他没有被视为管理员。
这可能与以下事实有关:我的Azure帐户有点旧,那里使用的LiveID很旧,并且Azure中没有DB的更新版本(v12的汇总于12月18日进行,因此也有可能需要使其正常运行)。我太累了,懒得检查一下,我意识到我不知道如何获得“旧”类型的帐户。此外,该问题将减少并逐渐消失,因为旧帐户最终会升级。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句