I made an application in Visual Studio 2013 using VB.net that works with my MySql database.
the program compiles and runs well when invoked through visual studio. However, when I run the application in the debug folder, I get the following error.
I have.
copied the MySql.data dll to the C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MySql.Data\v4.0_4.0.0.0__b77a5c561934e089
and referenced my project to that dll. -> Error does not go away.
i set local to true for this dll in VS -> Error does not go away.
Do you know how to solve this problem?
i had a similar problem. For your application to run, you need to install the MySQL DotNet Connector msi. here is the link https://dev.mysql.com/get/Downloads/Connector-Net/mysql-connector-net-6.9.8.msi. Download and install. Your application should now run ok
Related
I'm having issues running a .dtsx package made in Visual Studio 2019.
In Visual Studio when using "Start without debugging" it runs perfectly with no errors, however when I try to launch the file from command line it's giving me a non-descript error and terminates the package.
It runs for some time and does execute a few of the tasks at the start of the package, however it does not get very far.
This is the "error" showing in the command prompt:
Message: <DTS:ProcessMemoryUsage xmlns:DTS="www.microsoft.com/SqlServer/Dts">DTS:PeakWorkingSetSize177860608</DTS:PeakWorkingSetSize></DTS:ProcessMemoryUsage>
When I look at the error dump, this is what I see:
This is my execution command
"C:\Program Files\Microsoft SQL Server\130\DTS\Binn\DTExec.exe" /f "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\DataDropPrep\MSX DataDrop.dtsx" /conf "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\Test.dtsConfig" /DECRYPT "****" /CONSOLELOG /DumpOnError /REPORTING EW
I don't understand why it works perfectly when run within Visual Studio 2019 but not in the commandline.
The package is set with target server 2016 (To match our SQL server).
I'm running the package from a local VM on my own PC, but the SQL server is deployed in Azure (cloudapp.azure.com).
I am NOT a DB admin, so I can't add the package to be run from the SQL Server itself unfortunately, wish that I could, would make my life a lot easier.
Alas I am stuck manually running this package every day from my own PC, and I'm trying to automate it with a .bat file, so I need this command working.
This is the package layout, it first truncates a staging table, then loads all items modified or created in the past 3 days, then deletes matching rows in the production table, then imports the new rows from staging. Repeat for all the different objects:
When using "Start without debugging" from Visual Studio 2019, it executes without issues:
Turns out the issue was that I was using a project parameter, which works when running from Visual Studio, but not when executing the dtsx file directly.
After converting the parameters from project to package, it executes successfully!
Without the logging and the insights that provided I wouldn't have known where to start.
Success
In the same folder as the package, SSIS generated a file SQLDUMPER_ERRORLOG.log. This pointed to a file in C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps. This folder contains text files such as SQLDmpr0085.mdmp. When I click on this, it launches Visual Studio and gives an error message "The thread tried to read from or write to a virtual address for which it does not have the appropriate access."
After hours of experimenting and doing web searches, I discovered that I was not passing the correct package name to dtexec.exe. Once I corrected this, I was able to execute packages with no issues.
UWP App not being able to work with MySql
I have made an app in UWP and instead of using SQLLite which seems to be the norm for Visual Studio 2015 I want to use MySql. I have already connected my Azure mysql database to Visual Studio via the 'Server Explorer'.
I'm using MySQL Workbench to update my tables within my connected database from Azure but I cannot actually write any code to access my tables as whenever I try to install MySql.data/.entity/etc in the NuGet Package Manager I get an error.
nuget error
I tried downloading the Mysql installer, the Mysql drivers for Ado and ODBC. I even tried downloading the MySql for Visual Studio option as I found out that Visual Studio is not compatibile with MySql and instead requires the MySql for Visual Studio download but I still have errors whenever I try to use MySql in my code as I need an assembly reference for it but I'm having no luck in being able to get one that doesn't error.
Does anybody have any idea how I could actually use MySql within Visual Studio 2015?
This is what I've been using as my guideline but I can't seem to get past the Mysql.data errors when installing.
http://web3.codeproject.com/Articles/1074242/Designig-your-Azure-MySQL-DB-with-a-UWP-Demo
I have seen a lot of people talk about this but there is no one straightforward fix (I've tried a lot of the fixes, one in particular being to use Vs13 to install Mysql in the Nuget package manager and then it should update within VS15 but as my app is a UWP VS13 does not actually load/read it so that idea isn't good to me, might help anyone else though)
Starting with 6.7, Connector/Net fully supports building Windows Store apps. But using Connector/Net RT is not by install the Nuget package, it just reference the MySql.Data.RT.dll assembly according to MySQL Connector/Net Developer Guide:
Using Connector/Net RT is easy. Simply create a Windows Store application using Visual Studio and then reference the MySql.Data.RT.dll assembly in your project. The code you write should be exactly the same as for normal Connector/Net (including using same namespace MySql.Data.MySqlClient) except for the differences listed above.
You may find this dll at C:\Program Files (x86)\MySQL\Connector.NET 6.79\Assemblies\RT if you have install the connector. You can also download the mysql-connector-net-6.7.9-noinstall.zip to find this file inside the folder. I also have a MySql UWP sample before and has the dll here. Right click your project and add reference for this it will work.
More details please reference this sample
Using Microsoft's Release Management Server for Team Foundation Server 2013 v12.0.31101.0, I keep getting an error (included later). I can however successfully run the sqlpackage command from my local machine, the build server and the target SQL Server.
Steps taken:
I took the dll's and the sqlpackage.exe from C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin and copied them to a folder on my desktop
In Release Management, I created a new Tool with the command: sqlpackage.exe /Action:Publish /SourceFile:__FileName__ /TargetDatabaseName:__DatabaseName__ /TargetServerName:__ServerName__
I then added the dll's and the SqlPackage.exe from the folder I created a step earlier
Save and Close
I then created a new component which basically just wraps this tool (The Build Drop Location is a backslash to indicate the dacpac is at the root of the build folder)
I then selected the Tool I created and it filled in everything. I updated my release template to include and use the component
Putting the folder I created on any desktop, I can run the following command and it run just perfectly
sqlpackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /TargetDatabaseName:MyDatabase /TargetServerName:MyDatabaseServer
I did this from my local PC, the Build Server and the SQL Server itself, but when I use Release Management, I get the error.
Error:
An unexpected failure occurred: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception..
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SqlSchemaModelStaticState' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Update 1: I noticed on the error email from Release Management that the Target Server was my web server and not the SQL Server, even though the SQL Server was correctly named in the command. I checked the log on the web server and found the errors. I copied over my folder of dlls to the desktop and ran the script and voila, I was able to recreate the error. I checked the installed programs in Control Panel and noticed that the installed version of Transact-SQL ScriptDom was for 2012, version 11.0.2100.60. So I installed SSDT here. The installation failed because I don't have Visual Studio installed, but it still managed to install the 12.0.2000.8 versions of Transact-SQL ScriptDom and related dlls. When I ran the script again, it successfully published the database! However, when I tried to build from Release Management, I got a new error.
Publishing to database 'Logging' on server 'BYDWVCMNSQ01'.
Initializing deployment (Start)
Initializing deployment (Failed)
*** Could not deploy package.
Unable to connect to target server.
Update 2: So, I've confirmed the reason it was failing at this point was because the account that the build server was using did not have a login account to the SQL Server. I added the account and then granted it ddladmin and securityadmin privileges at the database I'm targeting. This yields a new error that I'm unable to create a new user, but at least I'm getting closer.
Final Update: I had to also grant sysadmin so the account could create a login. This allowed the deployment step in RM to succeed. This obviously is not the way I will leave it, I'll either use a publish profile or command flags to prevent the dacpac from being created with security objects and let it run with least privilege.
The issue of getting RM to deploy to SQL 2014 has been solved. The main issue was in my release template, I placed the DACPAC component inline with the rest of the build for my web server. This causes the DACPAC command to be run from the web server, and for that to work I had to install SSDT on the web server. I don't like this, and I'll probably rearrange my release template so that the web server and sql server are parallel, but nested under the same rollback.
On the server running the deploy, run procmon with a filter for the missing dll, then copy it into one of the folders it is looking in.
The correct way would be to install ssdt and the scriptdom bits (search for creating a headless ssdt build machine)
I had luck with this answer, switching from the old "SqlPackage" to the new one, I think it's some sort of confusion of related dll's:
To fix this issue, change the path to sqlpackage.exe to the new '140' version. The new path to sqlpackage.exe should be:
"%ProgramFiles(x86)%\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\SqlPackage.exe"
I have some custom control flow and data flow tasks that are not showing up in the SSIS Toolbox. When I open a package in SSDT containing the custom tasks I get several errors loading the package.
Error loading MyModuleTemplate1.dtsx: Cannot create a task from XML for task "__ECT Fetch Configuration", type "MyEncryptedConfiguration, MyCustomTasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2bdffe791d57af79" due to error 0x80070057 "The parameter is incorrect.".
I've followed Russ' and Matt's replies from the following post http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5fdf9243-7e38-401e-bf4a-9251738877f9/how-to-browse-the-installed-custom-task-in-sql-server-2012-ssis-ie-custom-ssis-control-flow-task, however, the tasks still don't show.
I'm using SQL Server 2012 x64 with SSDT on Windows Server 2008 R2 x64. I have verified that the tasks are in the GAC and that the assemblies are in the appropriate SQL Server\110\DTS directories. The assemblies have been compiled as 32-bit since I kept getting a warning about targeting Any CPU while referencing 32-bit assemblies (the SQL reference assemblies).
I'm able execute the packages with the custom tasks, on the target server successfully through command line. Additionally, these tasks work fine on my development machine. I can see the tasks in the SSIS Toolbox and can open packages with the tasks without issue. My dev machine is nearly identical to the target machine except that I have full installation of Visual Studio 2010.
Am I missing something?
This problem is the result of WiX installer not properly installing the custom tasks. Below is what I did to verify this.
For test purposes I created an empty custom task and manually deployed it to the target server by copying the files and the DTS\Tasks directory. This worked so I added the .cs file of one of the tasks that was throwing errors, to the test custom task and re-deployed. I was able to see both tasks. After cleaning the solution with the original custom tasks, I manually deployed the original custom task to the target server, like the test custom tasks and was able see the tasks in the SSIS toolbox. I then uninstalled the custom tasks and deployed them to the target server using a WiX installer -- the problem resurfaced. So the problem is with the installer. My previous attempts at manually installing the custom tasks failed because I was using the assemblies installed from the WiX installer, although I don't know why.
I have moved my packages to another server. Now on that server when I am executing my packages on visual studio then it is working fine. But when I am deploying the same package and try to execute it both via integration services engine or SQL Job.. I am getting below error
An error occurred with the following error message: "Cannot bulk load. The file "C:\ABC\PQR\XYZ\myFile.txt" does not exist.".
Edit
Somehow that issue is resolved but now I am into one more issue
Packages installed in MSDB is working fine when I am clicking on Run Package. But when I am creating SQL Agent job for the same packages it is not working.
I have tried setting "rely on server encryption" but no luck :-(
I would suggest to check whether folder C:\ABC\PQR\XYZ\ have read permissions for an account used to run SQL Agent jobs.
If this is **C:\ABC\PQR\XYZ** mapped drive connection then use the UNC path it worked fine through the server agent.