10 réponses à ce sujet

[JasonMel]

If anyone can, it would encourage me to keep looking for a way. Also, does anyone have ideas about how to run the toolset as a non-administrator account, other than "run as"?

Modifié par JasonMel, 02 janvier 2011 - 03:13 .

[JasonMel]

So everyone who uses the toolset runs it as administrator? Is it possible to "run as" administrator from a user account, and play/test your creation using the same user account as normal without conflicts?

Modifié par JasonMel, 30 décembre 2010 - 11:45 .

[Challseus]

Sorry, man, I don't have much to add, except to say that when I *was* on XP, I was the administrator, so I had no issues. Just curious, has running it as admin been working, but you are just looking for a more elegant solution, or even that does not work? Getting the notorius "Cannot connect to database" error?

[JasonMel]

Hey, Challseus, thanks for replying.

The toolset launches using a "run as" admin account. That error only happens if I try to launch it in my user account I use for everything other than admin tasks. I just want to make sure that I'm not headed for disaster by developing and playing on two different accounts. Don't applications normally store settings and things in the account in which it's run? I don't understand why DA has this limitation now, when BW got it right with NWN.

Modifié par JasonMel, 31 décembre 2010 - 05:42 .

[techwench]

The only reason the Toolset itself needs to run as admin is because it requires permission to access other things such as the sql database. All the stuff you create, however, are run from the user account. Of course...if you're logging into a different Windows user account to run the toolset, you'll have to transfer all of your creations over to the My Documents directory in whichever user account you plan to play on.

[JasonMel]

techwench wrote...

The only reason the Toolset itself needs to run as admin is because it requires permission to access other things such as the sql database.

Taking this information, I looked up SQL permissions and learned that I could run the toolset normally in my user account by changing to the Administrator account, running "SQL Server Surface Area Configuration" from the start menu, selecting "Add New Administrator," typing in my user account in "User to provision" instead of the default, selecting "Member of SQL Server SysAdmin role on BWDATOOLSET," and clicking the right arrow. Once I OK out of that and log back into the user account I just gave the permissions to, the toolset launched.

Thanks! If I run into any other problems with it, I'll report back.

Modifié par JasonMel, 02 janvier 2011 - 03:36 .

[FollowTheGourd]

Interesting that that worked for you. Are you running as a limited user, or just something other than the administrator (e.g., power user)? I'm still just running it as the admin user still. I tried what you mentioned, and I've even tried changing the connection string to use a user instance - which ironically only works when running as an admin. Even giving a limited user account full control over C:\\Program Files\\DAODB and the main toolset's sql dir doesn't help.

[b]HLKM/SOFTWARE/BioWare/Dragon Age/Toolset/Environment[/b]  and [b]DefaultDatabaseConnection[/b]:
[i]Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=bw_dragonage_content;Data Source=.\\\\BWDATOOLSET;[u][b]User Instance=true;AttachDBFilename=C:\\Program Files\\DAODB\\Data\\bw_dragonage_content.mdf[/u][/i][u].[/b][/u]

(never mind the forum doubling backslashes)

About the most interesting error message I can find is

2011-01-02 14:52:01.65 Logon       Login failed for user 'EDITED\\Edited'. Reason: Failed to open the explicitly specified database. [CLIENT: ]
2011-01-02 15:09:14.52 Logon       Error: 18456, Severity: 14, State: 38.

Just throwing this out there in general in case it makes sense to anybody.

Modifié par FollowTheGourd, 02 janvier 2011 - 09:20 .

[JasonMel]

FollowTheGourd wrote...

Interesting that that worked for you. Are you running as a limited user, or just something other than the administrator (e.g., power user)?

Yes, I think I set the account to be a "power user." Also, this is Windows XP Professional, and I remember changing the permissions regime to something that offered a higher resolution of control than the default. It's been at least five years since I set the accounts up, so that's all I remember. Sorry to hear the above steps don't work for everyone.

(Edit: Oh, also, before I did what I described, I first took the above steps using the administrator account itself in the "user to provision:" field. Maybe that makes a difference.)

Modifié par JasonMel, 02 janvier 2011 - 10:54 .

[FollowTheGourd]

Cool, it does work for me if I run the toolset under a power user account. Can't get it to work at all as a limited user, though - but good enough I suppose. I just went into "control userpasswords2" to set it to the "standard user" group (power users) - no other fancy settings. I'll add that somewhere to the wiki later - would imagine it also needs your solution of adding the account to DB, so it's not just using "BUILTIN/Administrator".

Looking at things quickly... you might want to check in all your module's resources back into the database with the previous account. Otherwise you'll see a red dot in front and can't check them out with the new account, not to mention there are pending changes.

What else is funny... running as a limited user I can connect to the DB just fine using the management tools. Just the toolset seems to have an issue.

Modifié par FollowTheGourd, 02 janvier 2011 - 11:22 .

[Obadiah]

I thought I read somewhere that the toolset needed to run with administrator privs because of some registry settings it needed to access? Never followed up on that myself.

[FollowTheGourd]

Obadiah wrote...

I thought I read somewhere that the toolset needed to run with administrator privs because of some registry settings it needed to access? Never followed up on that myself.

Not sure. I saw that entry in the troubleshooting page on the wiki, but I was able to read the keys - not write them, though as a limited user (e.g., update the connection string key). Didn't see anything weird with procmon, but filemon/regmon used to seem much clearer about when there were registry/file access issues going on.

Modifié par FollowTheGourd, 03 janvier 2011 - 05:44 .