We set up SQL server in a cluster. We then used one of the BizTalk servers and installed SSIS on it. We then configured BAM. Everything looked fine until we needed to run some of the SSIS jobs to archive stuff. They don't seem to have been created ...
We then tried to change the value in the MsDtsSrvr.ini.xml file and restart the SSIS on the BizTalk server and tested again but still no luck.
What do we need to do and where do we need to change the value in the MsDtsSrvr.ini.xml file?
In this post Richard S. discusses problem but I can still can't seem to get it to work ...
Difficult to say exactly what the problem is based on your comment.
Couple of things you could check:
Is your sql server database installed on a named instance?
What rights does the account that you used to run the install have?
Related
I am working on an asp.net application. Now I am working on to move it to windows azure server. After converting the project to the windows azure project it gets started to give me errors in accessing the database. I am able to access the data but the problem occurs where-ever I am selecting longblob type column and bit columns.
When running the application as normal asp.net application everything works perfectly but when I run it as the azure application from my visual studio, it starts to give "Arithmetic operation resulted in an overflow." when filling the data-table. After doing some research for this I found that this type of error occurs in when there are some special type of columns are selected in the select command. In my case the special data types are "longblob" and bit[1] in the mySQL database table.
Please suggest a solution to make this work in windows azure environment too.
This is a known issue for Hybrid Connection to access SQL server.
Please follow the temporary fix mentioned here https://blogs.msdn.microsoft.com/waws/2016/05/17/hybrid-connection-error-with-sql-server-system-overflowexception-arithmetic-operation-resulted-in-an-overflow/
I am having the same issue today as of last night. The application has not been updated in weeks. Everything I have read indicates it has something to do with using an int32 and the int being too large but the page the application is crashing on is not using an int in the code behind. I disabled all SQL on the page and it still crashes. I think this is something on the Azure side. Putting in a ticket with them. I'll keep you updated.
Here is what fixed it for me.
My Azure Web App was using the Azure Hybrid Connection to access my on-site SQL server. The server running the HCM also runs Azure Backup. One of my admins had updated the Azure Recovery Agent on that server.
After trying all sorts of things, uninstalling the most recent update to the Azure Recovery Services Agent is what resolved the issue. My Web App was able to access my on-site dbs without issue.
I had the same error when using an Azure hybrid connection with an onsite SQL Server. I did not have the Azure backup agent installed on the local server, however I did have Windows Server 2012 set to automatically update and there were a lot of updates which were pushed out on May 10 2016.
At this stage, I'm not sure which update specifically caused the problem, but I have narrowed it down to either 3146978, 3146751, 3146604, 3145384, 3144850, 3142026, 3135998, 3134179, 3125424, 3103616 or 3145432.
If you're running into issues with Azure Hybrid Connections, try uninstalling KB3142036 from the server which runs the Hybrid Connection Manager. Seems to have solved the SQL Server connection issues for me.
I have a couple of SSIS packages that resides on my local drive at work that run scheduled jobs. I will be leaving my current position in a couple off days, and would like to help my department transition smoothly.
My question is, for the person that will be picking up my duties, how can I transfer these dtsx packages to their computer short of recreating the packages from scratch on their local drive? If I'm not mistaken the SQL Agent runs off the user login account? After my last day my account will be deleted and none of the jobs will run.
Please provide some insight on what's the best approach. Thank you.
The best approach is to stop running things locally. SSIS packages should be set up and run on the database server and should use server accounts that won't disappear when people leave. We have a separate account for dev, QA, and staging as well as prod as some of the other environments are onteh same server.
While I agree with HLGEM about best practice, you have a couple of "quick and dirty" options.
One really dirty way is to mess with the service account that the SQL Agent uses. Usually it runs as Local Service or Network Service, but you can make it run under domain credentials that have access to the appropriate data sources. Careful, this is a big security hole.
SQL Agent also has a mechanism for running particular job steps under different credentials. Look into "Credentials" and "Proxies". This setup is really valuable at the server level, but is a lot of extra work just to run a job from a developer's machine.
Finally, there is no reason that SQL Agent has to be involved at all. You can run a dtsx package from command line or from an SSIS repository under the current user's credentials. This works fine if you are running packages as needed. Not so good for scheduled runs.
We have designed an application using .NET framework. There is a client application and a server application. The client applications, webpages, android/ iphone applications fetch data from the server using the WCF service.
My issue here is that some of the data that can be set by the user on the application is being saved on the server but cannot does not reflect on the client side once the application is restarted, we have designed the application in such a way that every change on the client side will be reflected on the server side, this is done to make this a cloud based application.
Some of the settings changed or value input on the client side is updating on the server successfully but does noes reflect on the client machines using the direct MYSQL service. However there are absolutely no issues while using WAMP as the MYSQL service, i.e the clients using the WAMP server can see the changes made. We have tried matching the versions and also have tried new and old versions of the standalone MYSQL. Firewall settings all seem fine. Since we prefer to install the standalone MYSQL over WAMP on our customers machines, it would be great if you could shed some light on the possible issues. Is there any difference in the initial config of MYSQL and the default config of WAMP MYSQL.
Hence if there is any thing in particular to note or tweak in this regards it will be really helpful.
Thanks in advance.
I don't think you'll get a really good answer to your question, because the term "WAMP" does not refer to a specific package, but rather any package that includes Windows versions of Apache, MySQL and PHP (and sometimes Perl instead of or in addition to PHP). See this link for a list of some of the available packages:
http://en.wikipedia.org/wiki/Comparison_of_WAMPs
Those packages come with different standard configurations for MySQL. Since you didn't say which WAMP package (and version) you were using, there is no way of knowing in what way their standard configuration differs from a plain MySQL installation (where the version is also important)
Have you tried just running a diff on the respective config files?
Is it possible to use MySQL local? I mean NOT at a server. I read a lot about MySQL on a webserver with PHP, Joomla etc.
I want to program a piece of software and use a database local to store results. Can I use MySQL for that?
If so, is ther anyware on the net a good tutorial how to do that?
You can install MySQL on your workstation, it doesn't need to be on a "server" per se. You still need to use something that can connect to it. From a Java application, for instance, you'd use JDBC; from .Net, you'd probably use ADO.Net; etc.
As far as I know, it will still want to have its server process (mysqld) running and for you to connect to that process via sockets and the like; there's no standard in-process version that I'm aware of. (The server can be listening only on the local interface, though.) There are several alternatives if you want in-process stuff, such as SQLite and HSQLDB.
Of course, if you're feeling really enterprising, there's the open source version of MySQL, which means you could compile it into your app (if you're using C or something that can link to it), but I suspect that's going rather too far. :-)
Yes, works like a charm for this.
Mysqls homepage has lots of info for this.
use SQLite. it is a popular embedded database.
It can be deployed via XCopy and no server installs.
But it can only be used locally. i.e if you later on decide to allow remote access, then you will need to migrate it to MySQL or other databases.
Try xampplite - it will painlessly install MySQL for you (on your local windows machine) as well as apache, php and a few other web apps if you need them.
If you don't want to install a server, you may be interested into Sqlite! It's the most widely deployed embedded database, and it's Public Domain.
http://www.sqlite.org/
Firebird is also an alternative. It's fully ACID-compliant and runs under the Interbase Public License.
http://www.firebirdsql.org/
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.