Silly question, perhaps.
I've developed an app on my machine that uses a Microsoft Access database (.mdb) to access certain information and populate a table with monitoring data using OLEDb.
The application works fine on my machine, but when I put the release on test machines (without MS Access), it crashes. Interestingly, if I were to launch the application on the testing machine with the database filename just renamed, it loads like it should albeit without the data.
I seem to get an UnauthorizedAccessException exception thrown which further clouds my confusion.
Both the development machine and the machine I'm testing it on have .NET 3.5 installed.
I would expect a barage of 'No's in reply to my question, but what the heck - does the testing machine need to have MS Access installed?
Regards
Try downloading the Office Connectivity Components here. This will let you read and create Access databases without having Access installed.
It doesn't need MS Access but you will need the required driver for your version of Access. You may need to do a test release that outputs to a log the exact Exception and message.
Make sure you have latest Jet 4 OLEDB drivers installed. There might also be a problem if you run the application from a network share (then it runs with restricted rights).
You say you got an UnauthorizedAccessException. I'd check read/write permissions to the .mdb file and location first.
If you're running as a service remember that they run under more restricted accounts.
You don't need Access itself. You will need to have JET drivers and associated files at least as current as the ones on your development machine — if you're recycling an old machine to use for testing that could be the problem.
However, this really sounds like a permissions issue, either on the database file itself or inside the file if you're using Access's security mechanisms.
It turns out the issue was a hardware problem. One of the serial ports on the card I was using had gone capput when it got moved to a new machine.
Turns out the problem wasn't database related, as the exception would've suggested.
Some interesting points on JET were raised though, which could be useful to anyone with Database access issues.
Thanks for your help guys.
Related
I have written an UWP app for managing employees, timesheets etc.
How do I detect if SQL Server Express is installed and if not installed how do I setup SQL Server Express on the client computer? Is it possible to do it without running the exe file in 'fulltrust'?
I would also like to include the setup files in my app package with the configuration file to run a silent install on the client computer.
I have looked for a answer on many pages but could not find a real straight forward answer.
Some help here would be much appreciated.
when you have access to your client computer, you can run a check program in your setup process via checking if MS SQL Server Express registry key exists or not. If it exists, then it is installed.
Read this doc from Microsoft, there is a code snippet in the doc you can use:
https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/express-administrator/bb264562(v=sql.90)?redirectedfrom=MSDN
What do you mean by 'auto-detect' MS SQL Server Express installed'? Not sure what's your use case here.
Normally, you can not auto detect database to use since in many cases there could be multiple databases installed in the environment, and you don't know which one is the right one you are going to use. You have to know which database you are going to use first.
However, if you insist to detect database, you can do the port scan in your network which is really not a good idea.
So guess maybe your use case is unique.
I'm attempting to use office interop to interact with Excel on a remote machine. The simplest-seeming way I found to do this was to use the Microsoft.VisualBasic.Interaction.CreateObject method, which is documented here. In my case, the call made to it is:
var excelApp = (Application)Interaction.CreateObject("Excel.Application", machineName);
However, this isn't fully working as expected. The results I'm getting:
When the machineName is the local machine that I'm running the code on, this works as expected.
When the machineName is a remote machine, an instance of Excel actually is started on the machine, but the CreateObject call fails with exception:
System.Exception: The remote server machine does not exist or is unavailable.
Googling this message doesn't reveal much of use, the results seem to all be people with different symptoms.
I don't really have any leads on what's causing this. I noticed that the method documentation page I linked previously rather cryptically states:
Refer to COM documentation (see Microsoft Developer Network) for additional information on making an application accessible on a remote networked computer. You may need to add a registry key for your application.
But I've yet to find that documentation.
Any suggestions for what could be the problem here? Or, failing that, a different way of achieving the same thing? Due to my situation, remote interop like this is a firm requirement- using Excel on a local machine to access a remote file is not sufficient.
Additionally, I would very much like to avoid a solution that requires a service or anything similar to be running on the Excel client machine, which as I understand it would be necessary if I wanted to use Activator.CreateInstance with a UrlAttribute.
The problem was a DCOM configuration issue. All the appropriate permissions were set, but the application was not configured to run as the interactive user. I suspect that this problem is relatively uniquely identified by the combination of being able to launch the process but not being able to connect to it afterwards.
The setting for this can be found in Component Services (dcomcnfg), under:
Component Services > Computers > My Computer > DCOM Config > Microsoft Excel Application. Right click this, select 'Properties', and configuration for which user account to run under is found on the 'Identity' tab.
An additional problem that I found along the way was that 'Microsoft Excel Application' was not initially listed in Component services, due to having 32-bit Excel on 64-bit Windows.
A solution for this, found here, was to run the 32-bit version of mmc (which can be done from the command line by starting with argument -32) and use the Component Services snap-in
I have a situation where I'm moving my .NET application to 64bit and I still need to read data from an Microsoft Access database from within C# code. I've had a suggestion where I could write a web service that reads the data periodically from the Microsoft Access and dumps it into SQL Server, so I could then read from SQL table in my application rather than accessing the Microsoft Access database directly.
This has issues like reading from the Microsoft Access database on a specific PC from the web service or WCF service. But I guess an account with relevant permissions would resolve this.
Has anyone else had a situation like this? If so, how have you worked around it?
Thanks in advance for any guidance.
An option might be to link the Access DB to the SQL Server. See Linking Servers on MSDN.
Can you use the ACE OleDb provider to connect your .Net application to Access?
It's a free download, available in both 32 and 64 bit versions. Microsoft Access Database Engine 2010 Redistributable
Note that if you also need to read xlsx in 32-bit application in 64-bit windows, Install MADE 2007 instead of MADE 2010(x86), because same version of MADE 2010(x86 + x64) cannot coexist.
I'm getting desperate so was hoping someone could help. We've re-written an old VB app that uses CDOEXM to create mailboxes in Exchange 2003. The new C# code is very similar and looks like this:
CDOEXM.IMailboxStore mailbox;
mailbox = (IMailboxStore)user.NativeObject;
mailbox.CreateMailbox(homeMDB);
user.CommitChanges();
The server running the code needed to have Exchange Management Tools installed for it to work (that installs the CDOEXM libraries that we require)
This works fine on XP, but we're also moving to Windows 2008 64bit servers, and I have been unable to install Exchange Management Tools on here because it says there's a compatibility issue.
Can anyone recommend a way around this? As I said, we're getting desperate because this is going to prevent a production release if we can't solve it, so would really appreciate some help.
Thanks
EDIT: incidentally I manually registered the CDOEXM dlls as a bit of a bodge, and I now get this error:
Problem creating mailboxSystem.ArgumentException: Value does not fall within the expected range.
at CDOEXM.IMailboxStore.CreateMailbox(String HomeMDBURL)
The homeMDBURL I am using is a valid one as far as I can tell though
I don't think CDOEXM is supported on Windows 2008. What about having a Windows 2003 Server around which hosts a WebService that does the mailbox creation stuff?
Another option is to create the mailbox without using CDOEXM. Note that this approach is totally unsupported by Microsoft. But if you populate enough properties (I don't know them all out of my head) like homeMDB and others, the Recipient Update Service (RUS) will create the mailbox on its next run. If I recall it correctly, the RUS runs every two minutes by default.
Btw, you did run your C# program as a 32bit process, right?
I am trying to solve a persistent IO problem when we try to read or write to a Windows 2003 Clustered Fileshare. It is happening regularly and seem to be triggered by traffic. We are writing via .NET's FileStream object.
Basically we are writing from a Windows 2003 Server running IIS to a Windows 2003 file share cluster. When writing to the file share, the IIS server often gets two errors. One is an Application Popup from Windows, the other is a warning from MRxSmb. Both say the same thing:
[Delayed Write Failed] Windows was unable to save all the data for the file \Device\LanmanRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elswhere.
On reads, we are also getting errors, which are System.IO.IOException errors: "The specified network name is no longer available."
We have other servers writing more and larger files to this File Share Cluster without an issue. It's only coming from the one group of servers that the issue comes up. So it doesn't seem related to writing large files. We've applied all the hotfixes referenced in articles online dealing with this issue, and yet it continues.
Our network team ran Network Monitor and didn't see any packet loss, from what I understand, but as I wasn't present for that test I can't say that for certain.
Any ideas of where to check? I'm out of avenues to explore or tests to run. I'm guessing the issue is some kind of network problem, but as it's only happening when these servers connect to that File Share cluster, I'm not sure what kind of problem it might be.
This issue is awfully specific, and potentially hardware related, but any help you can give would be of assistance.
Eric Sipple
I've heard of AutoDisconnect causing similar issues (even if the device isn't idle). You may want to try disabling that on the server.
I am having similar problems:
writing to a machine that is also part of a Windows 2003 R2 NLB cluster sometimes results in "Delayed Write Failed" or "the semaphore has timed out" or "the specified network name is no longer available"
this is reproducible for the same files, even after rebooting all machines involved
if I rename the problem-files (some of which are quite small), the problem remains
if I write the files to another location (fysical disk) on the same machine, the problem remains
I uninstalled all anti-virus software, problem remains
I have reset the tcp-ip stack, problem temporarily disappears, but after some time the problem returns for the same files
PARTLY SOLVED the problem:
I deleted (not stopped) the host from the NLB cluster. Problem solved.
Seems to have to do something with writing to a share on a server that is also part of a network load balancing cluster
I have not yet found other people posting NLB cluster related file write problems. However, I did find many posts complaining about similar problems, none of which seem to have been solved.
Anne
I've seen other people reporting the "delayed write failed" error. One recommendation was to adjust the size of the cache, there's a utility from sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx) that will allow you to do that.