| bio | website | |
|---|---|---|
| location | Pécs, Hungary | |
| age | ||
| visits | member for | 10 months |
| seen | Jan 31 at 14:45 | |
| stats | profile views | 7 |
|
Jan 30 |
accepted | Is it possible to create a trigger on a table synonym in SQL Server? |
|
Jan 30 |
comment |
Is it possible to create a trigger on a table synonym in SQL Server? No, I haven't. By the time I had the chance to try I already got the answer it was not possible, thank you very much. |
|
Jan 30 |
comment |
Is it possible to create a trigger on a table synonym in SQL Server? @billinkc: Random? Not at all. I have to test an application that creates several triggers on several tables and I made the very naive assumption that if it was possible, I could remove them before each test run by simply dropping the sysonyms (thus dropping the triggers on them as well) without affecting the original triggers on original tables. Now that I know it's not possible, I'll stop being lazy and create a proper removal script. |
|
Jan 29 |
asked | Is it possible to create a trigger on a table synonym in SQL Server? |
|
Oct 2 |
comment |
What's the difference between EXECUTE AS USER and EXECUTE AS LOGIN that makes the second one behave unexpectedly? Yes, we'll have to check everything affecting rights once again to see if there were other issues "fixed" this way. Not very happy right now :( Thanks again, Remus. |
|
Oct 2 |
accepted | What's the difference between EXECUTE AS USER and EXECUTE AS LOGIN that makes the second one behave unexpectedly? |
|
Oct 2 |
comment |
What's the difference between EXECUTE AS USER and EXECUTE AS LOGIN that makes the second one behave unexpectedly? Checked and confirmed. It was a member of sysadmin indeed. It turned out that this report has reached one of the other developers and instead of the correct solution he simply assigned the login sysadmin role. I wouldn't even think about that happening, I'm truly disappointed. We're going to have some serious talk when he comes back. Learned something new today, thanks. |
|
Oct 2 |
asked | What's the difference between EXECUTE AS USER and EXECUTE AS LOGIN that makes the second one behave unexpectedly? |
|
Jul 27 |
awarded | Scholar |
|
Jul 27 |
comment |
Data Collection reports fail because login is from an untrusted domain Then it seems this is the best I can get from the current environment. Thanks for the thorough explanation and most of all, the time you spent on me, Jon. |
|
Jul 27 |
accepted | Data Collection reports fail because login is from an untrusted domain |
|
Jul 27 |
comment |
Data Collection reports fail because login is from an untrusted domain Oh, I see. Or at least I think so. So, if I have two logins, both alike in dignity, I mean matching username AND password, one on the SQL box and the other one on the workstation (expediently, duplicating the one on the workstation to the SQL box), and giving it the required SQL permissions then I'll be able to run the reports, regardless of how restricted that login is in Windows on the SQL box, right? |
|
Jul 27 |
awarded | Commentator |
|
Jul 27 |
comment |
Data Collection reports fail because login is from an untrusted domain You're helping me a lot, Jon, thanks. I was able to accomplish #3 and while I'm pretty happy it works, I'm aiming at #2. A domaint acc was created and added to SQL Server with the required permissions but the problems start earlier. I cannot run anything on the workstation (with local login) trying different user using mydomain\mydomainuser for account. Not even Calculator is willing to start. I suppose I don't fully understand what 'impersonate it remotely' mean. |
|
Jul 26 |
awarded | Supporter |
|
Jul 26 |
comment |
Data Collection reports fail because login is from an untrusted domain Yes, the issue and its reasons have been ascertained yet I still have troubles with the workarounds. I don't understand the first one and cannot get the second one to work. |
|
Jul 25 |
comment |
Data Collection reports fail because login is from an untrusted domain let us continue this discussion in chat |
|
Jul 25 |
comment |
Data Collection reports fail because login is from an untrusted domain Oh, okay, it's clear now :) That's not possible at the moment. The SQL box was reached through a remote desktop connection by another developer when I asked him to try it locally. I've no direct access to the box itself, no account, no password whatsoever. Also, I didn't know it was possible to start an application on a computer using a login from another machine/domain!? Why is that necessary? |
|
Jul 25 |
comment |
Data Collection reports fail because login is from an untrusted domain I'm afraid I don't understand what you're trying to suggest me to do :( There are no different Windows accs on the workstation. And there are no SQL servers installed on it either, it only has the Management Studio. Its sole purpose is to connect to SQL Servers on different networks. Both reports (Data Collection or otherwise) are invoked on the workstation and fetch data from other machine. With the only difference that one of them works while the other one does not. |
|
Jul 25 |
comment |
Data Collection reports fail because login is from an untrusted domain That's why I find this weird. I'm not using Windows Authentication and I don't even know how it gets involved here. The SQL Server is running on a computer on the network of the other company. The network of our company is connected to that one using VPN. The workstation is on the network of our company but it is using a local account (I don't know if that's important or not). Management Studio is running on this machine and it connects to the SQL Server using an SQL Login. Other reports (like those for the server itself or for databases) are running properly. |