How to connect with MySQL from Visual C++ Microsoft Visual Studio 2008 ? I tried googling and found solutions all of which ended with fatal errors like linker errors,... etc. Please explain (or provide a link) step by step, including prerequisites (with links) and all details. I don't need any query examples.. just connecting to MySQL. Thanks in advance.
MySQL++ supports VC++ 2008, and comes with specific documentation on how to set up your project to avoid the link errors you're seeing.
Disclosure: I'm MySQL++'s maintainer
This worked for me (I am using xampp):
Open a C++ project (with precompiled header)
Change it from Debug to Release.
Install complete mysql (if you
install complete mysql, a C
connector will also be installed as a
include and lib file, which is not
installed in typical installation)
copy mysql/include to xampp/mysql
project > project properties > configuration properties > c++ > general > additional include
directory --> C:/xmapp/mysql/include.
Project > add existing item > lidmysql.lib (it’s found in
mysql/lib/opt.)
Copy libmysql.dll to c:\windows.
Alternativly we can copy it to the
project’s folder or we can set path
environment variable. But we only
tested it copy to c:\windows
Related
For 2 weeks I'm looking for a proper tutorial on how to fully install the library "lib_mysqludf_sys".
I got the .dll from a Russian site, because there seems to be no other for 64bit systems. I have successfully installed the procedure and also created the function, but whenever I want to call a file the whole database crashes. I conclude that the DLL file is faulty or that I forgot something to install.
can someone please explain to me how to use the UDF library to call files on a Windows Server 2016 64bit properly implied in the MySQL?
that would help me a lot, thank you!
Download the Windows 64 bit version from here:
https://github.com/rapid7/metasploit-framework/tree/master/data/exploits/mysql
Copy it to here or equivalent for your MySQL installation:
c:\Program Files\MySQL\MySQL Server 5.7\lib\plugin\lib_mysqludf_sys_64.dll
Install and verify as per the instructions here:
https://osandamalith.com/2018/02/11/mysql-udf-exploitation/
Looks like you are using MySQL 57/earlier version. For the library, I suggest to control it with "dependency walker". See if there is any problem with dependency libraries. At lease KERNEL32.DLL and MSCVTR.DLL (Visual C++ Redistrubatable file) should be there without any warning on root level.
If you have the code, I suggest you to recompile it with mygwin64. There are many items needs to be fixed to compiled it. Following link is a good link for UDF DLL compiles
https://github.com/esabilbulbul/mysql-udf-windows
There something similar, follow my answer here
stackoverflow.com/a/65209718/10026099
. Hi everybody!, I'm running into a small problem.
I have VS 2017 Community Edition, I've installed SSDT (SQL Server Data Tools)
I've built an SSIS package (a generic one) and now I would like to use it as a template for future packages.
So, I was digging in the web, also here in StackOverflow and found for example this article:
Setting up SSIS Item Template in SQL Server Data Tools for Visual Studio 2012
I found lot of other articles in MS for example:
https://learn.microsoft.com/en-us/sql/integration-services/create-packages-in-sql-server-data-tools
others, etc. and followed up to the tee but, for some reason I can't make it work.
This is my folder structure for my VS installation
I've left out of the tree some folders that doesn't apply to the problem
I put my package in the places I found in the articles and didnt work.
Sometimes, in the articles mentioned folders that I didn't have so I created and tried but nothing also (so deleted this folders)
I'm really lost, I tried everything I read, and some "creative things" from my yard but no results.
Anyone has come through this or has some experience about this issue?
Anyone can help?
Thank you very much.
Best regards and Happy new year!!
Gabriel
Well based on the articles I've read and the help of #billinkc, I finally figured out where to put the package, I was missing something also, but I realised when I read #billinkc answer.
When you are on VS Community Version, you have to put the package in this path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\SSIS\ProjectItems\DataTransformationProject\DataTransformationItems
The files you need to make it work are, a dtsx file (the package that will be the template) and a vsdir file which mainly needs to have this structure I used this values and worked fine:
YourPackageName.dtsx| |The name you want to appear|100|The description of the package| |21| |#44
You can check all the fields of the vsdir file in the MS documentation:
https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/template-directory-description-dot-vsdir-files
So now I have it running!
Thanks for your help!!
I don't have 2017 installed but this appears to work for 2015 so if you don't mind being a guinea pig...
Close out all instances of Visual Studio
Copy your template package into Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems
Open your SSIS project
Right click on the project and select Add, New Item and you should have your template package listed (TemplatePackage2)
For reference, below is what my folder structure looks like. Since I couldn't remember whether the package templates lived at DataTransformationProject or DataTransformationProject\DataTransformationItems, I put a copy of my template package in both, varying by name to see what was picked up in the editor
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationProjectItems.vsdir
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\TemplatePackage.dtsx
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems\DtsProjectItems.vsdir
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems\TemplatePackage2.dtsx
General notes about templates
The first is that the only way to get to your template is through the click path described above. If I want to add a new package, my default click path is right click on SSIS Package and select "New SSIS Package"
Pre-2012, the internal IDs of components and the package would remain the same. BIDS Helper had functionality to address this. Why it mattered was if you were attempting to track performance for packages, if they all report the same GUID you're going to have a hell of a time discerning whether Data Flow Task that ran for 10 hours is the same one that normally takes 10 seconds or was a second (different) package executed.
Developers will need to be local administrators on their machine to deploy the template package(s) and you'll need a process to keep that up to date. That or you need to engage the network admins to get these copied to developer machines.
Finally, if I had template logic, I'd probably abstract that away into Biml and then use source control to ensure people are working with the current version and avoids the whole permission issue.
I'm trying to use the sqlite-winrt library at https://sqlwinrt.codeplex.com (cf. http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/05/30/sqlite-winrt-wrapper-for-windows-phone.aspx) because I need to access an SQLite database via SQL commands in a WinRT 8.1 and a WP8 app and this library seems the only available option.
Anyway, there is no binary release and if I try compiling the source I get several link errors for unresolved externals against the SQLite DLL. I posted an issue at codeplex but got no reply yet, so I was wondering if anyone had already managed to successfully compile this lib and how (or if you know of any viable alternative for RT8.1 and WP8). Here is what I did:
downloaded the latest source from the site.
downloaded and installed 2 VSIX from http://www.sqlite.org/download.html: sqlite-winrt81-3080002.vsix for RT 8.1 and sqlite-wp80-winrt-3080100.vsix for WP.
executed the powershell scripts in each subfolder of the source code solution, which are required to update the projects with newer releases of the SQLite for WinRT extension. The current versions of the scripts refer to SQLite for WinRT 8.1 (prerelease) which is the same I downloaded above.
opened the VS2013 solution and removed the RT project (I just need RT8.1 and WP, this was for WinRT 8.0).
5) built the solution, which failed with link errors.
If I see the RT8.1 project properties, I can confirm the reference to SQLite is under C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\SQLite.WinRT81\3.8.0.2.
Did anyone manage to use this lib? Thanks!
I also once had that problem. I fix it by editing the project file manually. At that time, the powershell script updating the wrong path. That's why I always failed when compiling my project. After I edit the project file using external text editor (I use sublime text), the projects are linked correctly.
You can try DatabasesCx. It is another SQLite Wrapper using Windows Runtime Component technology. It is freeware distributed as precompiled binary. You can find the details at http://www.almanacsoft.com/databasescx
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.
I'm creating installer using InstallShield 2010 (basic MSI) that is having two features.
First feature consists of:
main .NET application compiled as x86,
some native x86 third party dlls which are used by main application (x64 versions are unavailable).
Second feature contains single component which is an extension for MS Reporting Services compiled as AnyCPU.
During UI sequence I'm using InstallScript custom action to enumerate all available Reporting Services instances from both x86 and x64 registry trees.
The user is prompted to select on which instance he wants to deploy our extension.
Based on selected instance I'm quering registry for actual location of Reporting Services in file system which is usually something like "C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services" and storing this value in a MSI Property.
Then by using Set Directory action I'm setting destination directory of a component (our extension) to the value of that MSI Property.
Everything is installing perfectly fine unless you've trying to install it for x64 Reporting Services in that case extension files are installed to wrong location. Even thou MSI Property is set to correct path "C:\Program Files\MicroSoft..." (I've checked msi log) it looks like system is automatically redirecting to "Program Files (x86)".
Is there any possible solution to overcome this issue?
If you need to install to the 64-bit ProgramFiles folder, use a 64-bit MSI.
Finally solved this issue myself without creating 64bit MSI by using InstallScript custom actions.
First custom action to install:
Manually copy required files to desired location (InstallScript can access x64 Program Files)
Save this location in registry as a key component for this feature to use during uninstall
Second custom action to uninstall:
Read installed location from registry (do not use System Search to get this value due to it'll be auto translated by WindowsInstaller to "ProgramFiles (x86)")
Delete files
You can change the INSTALLDIR property to ProgramFile64 rather then ProgramFiles, this will help you to install on desired path, since you application is 32-bit so the path will be C:\ProgramFiles(x86)\Your Company Name\Your Product Name along with this have you made your components as 64-bit compatible?