Have a working Service Broker set up on a server, we're in the process of moving to a new server but I can't seem to get Service Broker set up on the new box.
Have done the obvious (to me) things like Enabling Broker on the DB, dropping the route, services, contract, queues and even message type and re adding them, setting ALTER QUEUE with STATUS ON
SELECT * FROM sys.service_queues
gives me a list of the queues, including my own two, which show as activation_enabled, receive_enabled etc.
Needless to say the queues aren't working. When I drop messages into them nothing goes in and nothing comes out.
Any ideas? I'm sure there's something really obvious I've missed...
Just a shot in the dark:
ALTER AUTHORIZATION ON DATABASE::[restored db name] TO [sa];
The dbo of the restored database is the Windows SID that created the db on the original server. This may be a local SID (eg. SERVERNAME\user) that has no meaning on the new server. This problem usually affects activated procedures and may affect message delivery, both issues happening due to inability of SQL to impersonate 'dbo'. Changing dbo to a valid login SID (like sa) would fix it.
If this doesn't fix it, then you need to track down where do the messages go. If they stay in sys.transmission_queue, then you must check the transmission_status. If they reach the target queueu but no activation occurs, check ERRORLOG. If they vanish, it means you do fire-and-forget (SEND followed immediately by END) and you are therefore deleting the error message that indicates the cause. This article Troubleshooting Dialogs contains more tips where to look.
And last, but not least, try using ssbdiagnose.exe.
In addition to Remus's answer, You might also want to check the BrokerEnabled property of the restoredDB. Whenever you restore a DB, the BrokerEnabled property of the restored DB is set to False. For this reason nothing will go into your queue. To address this:
right click on the restoredDB in SSMS > goto "Properties" > "Options" >
Scroll down to the "Service Broker" group and verify the value of the "Broker
Enabled" property. If it is set to False, change it to True and this
should solve your problem.
Related
there is a view as above. but i cannot get inside of it. but when i write the select, it give me the data and ask for commit or rollback
My issue is that Actual cost is wrong. SO i need to correct it. but not able to go inside and see what is happening there.
Do you guys have any idea of what is this '#' sign and why it is not allow to inside?
why it ask for commit?
Oracle says that it is possible to crate table name with '#' sign. but this is not it.
I am using PL/SQL developer
Guidance ? :)
Yes, it happens when selecting from a view via a database link.
This is why: Controlling connections established by database links (https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_appdev002.htm#ADMIN12194):
When a global object name is referenced in a SQL statement or remote
procedure call, database links establish a connection to a session in
the remote database on behalf of the local user. The remote connection
and session are only created if the connection has not already been
established previously for the local user session.
The connections and sessions established to remote databases persist
for the duration of the local user's session, unless the application
or user explicitly terminates them. Note that when you issue a SELECT
statement across a database link, a transaction lock is placed on the
undo segments. To rerelease the segment, you must issue a COMMIT or
ROLLBACK statement.
As you're just selecting, it doesn't really matter whether you'll rollback or commit (I push the rollback button). After that, recreate the view so that it calculates the correct value you've mentioned.
I have an on-premise CRM 2016 instance and I can't receive any incoming emails inside of it even though when I run the test access says everything is good.
First, I'm unable to change a queue record email address, because I keep getting a SQL timeout error (doesn't matter how much time you increase the timeout it will never change) but if I try to change any other field it works and saves (but not the email field of course).
The same with the Mailbox's records, when I try to change the email it returns a SQL timeout error.
So what I did was change these emails by SQL queries, but after that the emails still won't create inside CRM.
It shows the next warning log in the event viewer:
35241 - The recipients for the email message with subject "[x]" in mailbox [email address] did not match any known records.
I'm running out of choices here, when I run the diagnosis tool on my organization it's performance is good but there must be something obstructing the communication with the SQL? Any clues?
SQL timeout error:
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: SQL timeout expired.Detail:
-2147204783
SQL timeout expired.
2018-10-10T14:14:15.5749939Z
I got the answer from Microsoft Community Forumns, thanks to Radu Chiribelea:
It's not enough to change the email address in SQL in it's base table for a record, so that this can be used for email tracking. There are other references as well - for example the EmailSearchBase. This is why you need to let the platform handle your changes.
You biggest issue here is the SQL Timeout and that is what you need to address. Since this occurs at a Create / Update I suspect there might be a deadlock somewhere. Do you have any plug-ins or workflows triggered at the time you create / update? If you disable those, do you still see the issue?
Can you enable a CRM Platform trace at a Verbose Level while reproducing the issue? This would give you a better overview of the actual timeout and you can then start from there to tackle it.
I have used SQL Service broker and SQL Table Dependency and started SQL table dependency in a table for notifications on table data change. I have given all the permission to database listed in SQL table Dependency document. After some times, may be in idle state it is giving status as "Waiting for notification" .
When I change in table (inserting new record), status is not changing (From waiting for notification) and gives error as "The conversation handle "A705917C-4762-E711-9447-000C29C3FCF0" is not found."
Can anyone help me to fix this issue?
First read this comment please:
There is one very common scenario that results in much more time:
debugging. When you develop applications, you often spend several
minutes inside the debugger before you move on. So please be careful
when you debug an application that the value assigned to
watchDogTimeOut parameter is long enough, otherwise you will incur in
a destruction of database objects in the middle of you debug activity.
Reference
On the other hand
If you are using SQLDependency and get an error like this:
The conversation handle
"206A971D-6F25-DA11-B22F-0003FF6FCCCA" is not found. Invalid object
name 'SqlQueryNotificationService -
41136655-4314-4536-a477-37156eb628db'.
Then try enable trustworthy :
Alter database [DbName] set trustworthy on
The TRUSTWORTHY database property is used to indicate whether the
instance of SQL Server trusts the database and the contents within it.
By default, this setting is OFF, but can be set to ON by using the
ALTER DATABASE statement. more information
Thank to Scott Hanselman for his answer
We are running into a few issues with our TFS installation (TFS 2013 Update 4, SQL 2014 Standard) as a result of email alerts. Most notably, Work Items cannot be created, because this triggers an email.
Any time a process or user attempts to create a Work Item, the error
TF30040: The database is not correctly configured. Contact your Team Foundation Server administrator.
is received. Further, when I check the Event Viewer on the server, I can see the error and it reports that the inner exception is:
Exception Message: The EXECUTE permission was denied on the object 'sp_send_dbmail', database 'msdb', schema 'dbo'. (type SqlException)
I have worked with the DBA and we have enabled Email Alerts on the server. We have verified that, in general, the alerts work by using the test button on the administration console. I can also set up a check-in alert through the web interface and receive said alerts without issue. This seems to be specifically affecting Work Item creation alerts (which apparently are just automatically and irrevocably enabled).
Presumably, we could correct this by giving appropriate permissions to use that stored procedure. To do so, we need to know what user to give permissions to. So far we have tried giving execute permissions to my AD user, the service account used by the build service, and the Network Service account (which appears to be the TFS Service Account).
There is no indication in any error message as to what user is being used to execute that procedure. So, my question: What SQL user is used to send alerts when creating Work Items?
Edit:
For the record, this started working of its own accord. We decided Monday to call Microsoft to get this fixed. Before that happened, failed builds magically created some work items (on Tuesday, a full day after we gave up), and we are now able to create work items. Everyone involved states not doing anything. We are baffled, but in a good way.
I'm going to advise you that a DBA should not be making changes to the TFS databases. I suggest opening a ticket with MSFT and getting assistance from the product support group.
We are developing an application that will use service broker to transfer messages from one database to another. SourceDB is used by an existing application from which we are siphoning off some data. TargetDB is used only by this application and processes/distributes the data we need. We are only using one type of contract and both DBs are on the same server.
We have set up identical message types and contracts on both, and respective initiator and target queue/service. On both databases:
ENABLE_BROKER is set
TRUSTWORTHY is set
Have a unique service_broker_guid
Have sa as db owner, with all SSB authorization statements are dbo or OWNER, as appropriate.
However, when we send a message from SourceDB:
BEGIN DIALOG CONVERSATION #dialogHandle
FROM SERVICE [//Service/Initiator]
TO SERVICE N'//Service/Target'
ON CONTRACT [//Contract/Notification]
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION #dialogHandle
MESSAGE TYPE [//Message/Notification] (#RequestMsg);
...messages do not find their way there. Further investigation reveals the following:
The initiator queue is empty
The target queue is empty (NB: not an issue of needing to RECEIVE)
The transmission queue is empty
No errors are recorded, either in the SQL Server logs or in our CATCH error handling in the stored procedure that creates the message
The initiator queue's entry in SourceDB's sys.dm_broker_queue_monitors is set to NOTIFIED if activation is enabled
SourceDB's sys.conversation_endpoints has a new entry in CONVERSING state
The target queue's entry in TargetDB's sys.dm_broker_queue_monitors remains INACTIVE if activation is enabled
TargetDB's sys.conversation_endpoints has a new entry in CONVERSING state with the same conversation_id and different conversation_handle from SourceDB's entry
Although the test database is SQL 2005 (application must support 2005), I ran the ssbdiagnose utility from my development machine's 2008 installation to dianose the issue:
ssbdiagnose -S testserver -d SourceDB CONFIGURATION FROM SERVICE //Service/Initiator TO SERVICE //Service/Target ON CONTRACT //Contract/Notification
That produced the following:
D 29912 dbtestsvr SourceDB Service //Service/Target was not found
D 29975 dbtestsvr SourceDB User dbo does not have SEND permission on service //Service/Target
This is confusing, since dbo should not be denied any permission, and //Service/Target certainly does exist, albeit in a different database. But my coworker ran a Profiler trace that showed a command being executed looking for //Service/Target on SourceDB. Service broker seems to be getting confused somehow. Adding an explicit route, in addition to being theoretically unnecessary, does not change the situation.
I ran a nearly-identical set of tutorial commands on our test server and everything worked fine, so it is likely something db-specific.
Our setup was working two days ago, so we're probably looking for some setting that might have gotten changed, but with no luck.