I'm using VB2010 and Access.
My connection string works absolutely fine
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=E:\Database1.accdb;Persist Security Info=False;"
I have the Access Database Engine installed on my machine and I'm trying to add the ACEOLEDB.DLL to my references but I get the following error
The file exists but I can't add it. I'm assuming by adding the dll it will rule out the need for the end user not to install the Access Database Engine??
If you simply want your application to be able to use System.Data.OleDb objects with the Microsoft.ACE.OLEDB.12.0 provider then you don't need to add any references to your VB.NET project. The ACE OLEDB provider is registered with Windows when the Access Database Engine is installed.
I'm assuming by adding the dll it will rule out the need for the end user not to install the Access Database Engine?
That is incorrect. The appropriate version* of the Access Database Engine will still need to be installed on each machine where your application will be running.
* (That is, 32-bit or 64-bit, the same as the "bitness" of your application.)
Related
I have a computer that is used for getting database information from the server in the same domain, and this computer is used by employees who don't have the server admin information.
When the computer restarts, I'd like it to automatically log in to Windows Server so that it can access the database files. Is it possible to write a script for this that runs on boot?
Thanks in advance
I solved this by adding the credentials to the Credentials Manager in Windows, along with disabling the Windows Server dashboard program. This makes Windows automatically log in to the server with the stored credentials on boot.
Since your question really isn't specific, I'd like to suggest two ways of accomplishing your goal.
Since you'd like to access database information, why not use some kind of database management software (like SSMS if you're using MSSQL) and set up proper permissions for the user/computer that will need to obtain information from that particular server/database.
If you need access to raw files (which doesn't make much sense in case of MSSQL for accessing purposes), why not set up proper permissions on the file or parent folder, giving the user that is logged to the client PC proper permissions to access the files that are of interest.
I'm having trouble accessing an external database from a CRM plugin.
The error I receive is:
"Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=xxx' failed."
The code runs great locally within a "unit test". I made sure to set the plugin isolation mode to "none".
I tried looking to this article for help, and tried everything it suggested with no luck.
Here is the current code I'm using:
var conn = new SqlConnection(#"Server=MyServer\Instance;DataBase=MyDB;User Id=MyUser;Password=MyPassword;Integrated Security=false;");
conn.Open();
I also tried this connection string and giving the NT AUTHORITY\NETWORK SERVICE user access to the database.
var conn = new SqlConnection(#"Data Source=MyDS\Instance;Initial Catalog=MyDB;Integrated Security=SSPI;");
conn.Open();
I'm on Dynamics CRM 2015 On-Premise.
Update: I found out it was working when I didn't debug, but I got the error when I try to debug it through the plugin registration tool. Any idea on why that would happen?
A SQL connection will require "full trust" to establish which the CRM plugin sandbox does not run within.
We run CRM 2013 On-Premise and I frequently make calls to external databases within custom plugins and workflows, but to overcome the security issues - I created a web service which handles these requests.
For example, a call to update a record in DB2 when an account is updated would work like this:
Account record updated in CRM
Account plugin fired
Establish connection to MyCompanyWebService
Call UpdateDB2 (method within MyCompanyWebService)
Of course you have the overhead of having to develop a separate web service, but (on the bright side) it allows you to separate the logic and you can fully control the trust level within your web service.
The plugin registration tool has only limited debugging capabilities. It was designed for CRM Online, where you cannot use the debugging options of Visual Studio. In OnPremise deployments use either remote debugging or install Visual Studio on the CRM Server. The last one is the recommended approach.
That issue looks like your code is running in partial trust (Sandbox), it's failing even before trying to connect to the SQL Server instance as it doesn't have permissions to instantiate a SqlClient.
In Dynamics CRM 2015 On Premise you don't have to run plugins in Sandbox if you don't want to. Sandbox is a requirement for Dynamics CRM online only.
Did you try running outside the Sandbox? Did you do an iisreset after changing the plugin isolation maybe?
Here is an article with more details.
I'm working on an MVC3 site, and I've got a puzzling problem with ASP.NET Membership. I'm using System.Web.Providers 1.0.1 connected to a SQL Azure database.
As it is now, the same username/password that logs me in when running under the Compute Emulator fails when running under Azure proper. I can see that it's using the right database, as the Failed Password Attempts counter in the membership database is being updated.
I tracked it down, thanks to some info in this article by David Hoerster. The problem is that the default password hashing algorithm on Azure is different from the .NET 4.0 defaults. It is set to SHA1 on Azure, and HMACSHA256 is the new standard setting on 4.0.
This can be fixed by specifying the hash type explicitly in web.config. If you decide to use a method like HMACSHA256, make sure you also specify a machine key - otherwise you will run into similar problems as the autogenerated machine key will differ from server to server.
The configuration element you need to change is <machinekey> under <system.web>:
<machineKey decryptionKey="PUT_DECRYPTION_KEY_HERE"
validationKey="PUT_VALIDATION_KEY_HERE"
decryption="AES"
validation="HMACSHA256" />
You can use this machine key generator to generate random keys in the proper format.
How can I simultaneously access my .db4o database from the Visual Studio's Object Manager Enterprise (OME) db4o plugin and from my application?
I'm starting out with db4o, integrating it with an ASP.NET MVC application. I have a two-layer repository access pattern set up using StructureMap for IoC and I keep getting DatabaseFileLockedException erros in VS when debugging while using OME.
When you want to access a db4o database file from multiple applications at the same time, you need the client-server-mode. So, either your application or a special "db-server only" application has to open the file as server, then both your application and the OME should be able to connect to this server.
The documentation has an example for this.
I never used OME, so I have no idea how to configure it there.
I make a software using C# & my database is msaccess..Now I want to make a gateway which will be install in all pcs in a local network & i want to make connection with that database which is in a single computer...but i dont know what is the procedure to do that in C# windows application..please solve my problems...thanks..
I try to upload my data from client pc to the database which is in a server..I dont know the codeing to do that..pls send me some code for that...advanced thanks..
It would be helpful to know a bit more about what you're trying to achieve (you can edit your question to provide more information) but fundamentally you've got two options:
As its an access database you can put the .mdb file in a shared folder and it will be accessible to multiple instances of your application (store the location in the configuration data for your application). This will work - in some cases very well - but access can be a bit slow running over a network as its all file based.
Create a self hosted "web" service (WCF ideally, but I can't remember what your options are for VS2005) that provides the methods you need to interact with the database and then connect from your client applications to the "server" application over the network.
The "best" solution will depend on the detail of your problem and what you're trying to achieve. If each instance of the application accessing the database directly is the preferred choice then I'd strongly advise you look at using SQL Server Express instead of access.