Problem solved. The key was that it wasn't saying it couldn't find msjter35.dll (the file was clearly there) it was saying it couldn't load it. After some digging, I discovered that msjter35 has a dependency on msjint35.dll and it was that latter file that was missing.
I have no idea how the machine was delivered to me in this state, but copying msjint35.dll to SysWow64 solved the problem.
Is there any setting in SQL Server when I am creating a stored procedure, it can automatically generate documentation for me that who is creating who is updating, date time of creation and update etc instead me typing all that by myself. Just like in the below example.
/* NAME : [Usp_Get_vvvvvvById] /
/ PURPOSE : THIS STORED PROCEDURE RETRIEVES LIST OF vvvvv codes /
/ TABLES USED: /
/ [dbo].[xxxxxxxxxx] , [dbo].[xxxxxxxxxxxxxxx] /
<h2>/ VERSION HISTORY:- */</h2>
<h2>/* VERSION NUMBER| DATE | AUTHOR | CHANGES */</h2>
/* 1.0 | 10/18/2017 | xxx | INITIAL VERSION */
I want it can be generated automatically instead of me typing every-time, anybody can help me please, any help can be a great help - thanks in advance.
"There is already enough hatred in the world lets spread love, compassion and affection."
I presume that you mean when you are in an editor and start a new proc.
Rather certain that Visual Studio provides that straight out of the box. Certainly has for a very long time for other languages like C#. There is or at least was something named something like 'template' which was invoked every time one created a file of a new type.
Hi I have a SQL Agent task which sends an email to all staff. The email is different because it sends it to a group which has "require that all senders are authenticated" ticked in their settings. This task works fine from one node in our availability group. I've copied the job to a secondary node and it says successful but no email is sent. We've investigated and can see a blocked email with the error: "Your message can't be delivered because delivery to this address is restricted".
I have restarted the SQL Agent service which didn't make any difference. The database mail looks to be configured in exactly the same way it is on the other node where it works fine. Any ideas why it is not authenticating properly please?
A reboot is an option but we'd rather not do this.
I suspect that message is originating from your email service not your application. So your service is attempting to send email via an API call to a server, and that server is telling you that it doesn't like what you are doing.
That is a configuration issue and probably one that can only be fixed via the email service. As a guess perhaps there is a security restriction based on IP/DNS (box of agent) and it needs to be updated.
Thanks for your help and reply but I think the solution isn't to change the security setting on the email group - it is to ensure that the user authentication is completing successfully. This is what I have no idea about how to check. A reboot of the node may resolve it but I'd like to think it may be caused by a SQL Server user configuration setting that I can test/change and resolve without the need for a reboot.
I'd like to understand more about the problem as I don't have much knowledge of diagnosing this user configuration/authentication.
We are migrating to a new server, since the location of the server has changed. With that said, we are process of migrating over the report server. I backedup and restored two databases "ReportServer" and "ReportServerTempDB". We have configured the reporting services.
Now we have many reports, that have the datasource specified within the report as well. There are a total of 426 rows in the "DataSource" table. How do we find the datasource for these reports? The table has mostly encrypted values.
We're about to migrate from SQL Server 2008R2 to SQL Server 2016. We have SSIS packages in both the package store and the file system. I want to establish a standard beginning with this migration so that we always put packages into the same location.
So, package store, or file system, and why?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Since the package store allows you to store your packages in either the File System or the Database I suspect the question you you actually want an answer for is whether to store your packages in the File System or the Database. The package store itself is more of a management solution.
Pros for Database: One point of backup, and probably easier to handle in a multiple instance system. Easier to use from any server or client.
Pros for File System: Easier to export/import between systems. Just copy the files.
I suspect it's mostly depends on how you work and develop your packages, I would also guess there are security concerns to think about.