I'm trying to connect to an access database .accde type from a Visual Basic project in Visual Studio.
While I can connect from an Access application to that .accde without any problems, It seems that this kind of file is not accepted by Visual Studio.
This is a drawback, because the file must be protected by a password, and generating it as an .accde allows it.
Anyone can give any clue to solve this issue?
Related
I have an application using vb.net with MYSQL database in visual studio 2015 now i need to create a installation package to deploy the application to client computer.
I don't have any idea how to do this please anyone give tips how i can do this, im new with MYSQL.
It depends, what technology are you using? If you are using entity framework you should have a .config file in your project, usually it's called app.Config, you can specify your <connectionStrings> there. Else if you use SqlConnection, you'll have to change that string.
I need Help
I recently just created a program using Visual Studio 2017 with C#, i'm using Microsoft Visual Studio Installer Project Extension to create the installation.
i've tried installing the program in PC i used for programming (I created the database directly from Visual Studio Without sql management studio) and there's no problem there but
i faced a problem where after i Installed the program in different Computer, the Database turned into a fail
Failed to update database "C\... .mdf" because the database is read only.
i don't have sql management studio installed here as well. I've already tried to change the allowance from all the users on this PC but it still happenning.
so if you guys have any idea on what should i do that would be a lot of help.
After deploying my reports to the reporting server, I tried to add a subscription on one of my reports. It was not possible, and I got the error as described in this link.
http://www.kodyaz.com/reporting-services/subscriptions-cannot-be-created.aspx
All my reports use the same shared data source.
I applied the solution proposed in this link and it worked.
BUT Each time I deploy my reports (from SQL Server Data tools for Visual Studio 2013); the error comes back.
I tried to modify the properties of the shared datasource with SQL Server Data tools for Visual Studio 2013 before deploying;similarly to what is shown in the hyperlink, but in this case I am not able to access my reports anymore.
So, it seems that I could only modify the credentials "online" with my web browser; and not "offline" with SQL Server Data tools for Visual Studio 2013.
I remarked one difference between the "offline" and "online" properties of the shared data source : online, it is possible to check the box "Use as Windows credentials when connecting to the data source". This checkbox does not exist in SQL Server Data tools for Visual Studio 2013.
This means : each time I redeploy the reports from SQL Server Data tools for Visual Studio 2013, I have to do the online manipulation on my web browser to get the subscriptions working; which is of course really annoying...
Does someone know how to fix it?
Thanks in advance and sorry for my poor English.
I had a similar problem. I solved it by simply deploying the whole project and not only the shared data source.
Macros and VB macros are very limited in Access.
I've good C#/.NET skills and created an app with System.Runtime.InteropServices.Marshal.GetObject (captures some process) to use with Microsoft.Office.Interop (makes some Office stuff).
It's works like a charm with .accdb files (MS ACCESS 2010), but when i want to automate mdb base with security...
For example, i can't get Access process with opened DB:
C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE \server\database.mdb /WRKGRP "\server\security.mdw"
New process just starts.
I decided to create an Office Add-In for Access 2010... but when user opens shortcut above - it's just not loading.
Is there any possible solution to open/get/capture Access process with opened mdb database?
upd1: i'll try to play with msaccess cmd startup arguments
Got it!
http://support.microsoft.com/kb/317114/
Look at GetShellApp method - you can pass any arguments and connect to encrypted\user-based-access DB
I have the Bullzip MS2mySQL converter and another converter by Convert-In.com installed. I am working with a MS Access 2010 accdb file which is working fine in Access but gives errors in both converters. Both converters work fine when used with an old Access 2007 mdb file.
The Bullzip converter error is "Error 3706: Provider cannot be found. It may not be properly installed." I have an open forum topic over there but I have open topics there which are months old with no replies at all.
The Convert-In converter's error is "Unrecognized database format". Their docs specify Access 2010 support while Bullzip does not make mention of versions supported.
The Access Save As dialogue is not offering me any options other than 2010 accdb.
Does anyone have any advice on this? Client needs to continue using Access as GUI but I need to fluidly port data to mySQL for our web apps.
// EDIT
My copy of Access 2010 only offers accdb even for new files. So I tried creating a new database in accdb format with 2007 as the version and imported only the tables from the problem file. No forms or queries etc. Same errors from all converters tried.
// EDIT 2
Per HansUp's suggestion to import data into another file - I changed version to Access 2003 and mdb shows up as format and file is opened by converters!
"The Access Save As dialogue is not offering me any options other than 2010 accdb."
Sorry, I don't have Access 2010 so don't know why it won't let you save as MDB. However, since that option is unavailable, create a new MDB, then open it and import everything you want from the old ACCDB into the new MDB. Sounds like you would then be able to use your converter utilities with the MDB.
If at all possible, I would prefer to replace the native Access tables with ODBC links to their MySQL counterparts. With all the data in MySQL, you could avoid the challenge of synchronizing data between Access and MySQL.