4

We recently moved from Windows XP to Windows 7. We found that one part of application in C# that try to create a dbf file for a PDA failed thorwing an error message "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."

I found many forums pointing me to build my exe as 32 bit like here.

My Question No. 1) Is there any other driver for accessing dbf on a 64 bit OS machine? (I know there is one for accessing excel and access db). Anything there for dbf?

Question No 2. same as my Title. I have a feeling that by converting to 32 bit, I am not making use of the full advantage of a 64 bit. so What am I losing by this workaround?

Thanks in Advance.

Community
  • 1
  • 1
franklins
  • 3,710
  • 6
  • 41
  • 56

5 Answers5

2

In response to your second question, 64-bit doesn't get you that much unless you want to store huge amounts of data in memory. Most developers still target x86 (32-bit) because there's a lot less hassle with it. That said, there are cases when 64-bit systems operate better but, as I said, it's mainly to do with the amount of memory you want to consume.

Dmitri Nesteruk
  • 23,067
  • 22
  • 97
  • 166
2

In response to your first question, a 64-bit machine attempting access on a database with 32-bit software through the MS engines needs to have the Data Connectivity Components installed:

http://www.microsoft.com/downloads/en/details.aspx?familyid=7554f536-8c28-4598-9b72-ef94e038c891&displaylang=en

Joel Etherton
  • 37,325
  • 10
  • 89
  • 104
  • Um, "32-bit database" is a misnomer. – Seva Alekseyev Feb 23 '11 at 15:23
  • Thanks, I tried the above exe (infact a 64 bit one from http://www.microsoft.com/downloads/en/details.aspx?familyid=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en&WT.mc_id=soc-n-[TR]-loc-[Services]-[farukc]". But again looks like this solution is only for xls, or mdb files and not for dbf. – franklins Feb 23 '11 at 15:25
  • @fabraham - I saw that, and I apparently did not read your question thoroughly enough because I missed the .dbf part (a recurring theme for me today it seems). @Joel Coehoorn has the appropriate answer. – Joel Etherton Feb 23 '11 at 15:27
2

With x86 you are saving memory and making it easier to use Edit-and-Continue. On the minus side you are limiting your address space. See some rationales for 1) not making VS 64-bit and 2) making the default for new apps created in VS 32-bit:

1: http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx

2: http://blogs.msdn.com/b/rmbyers/archive/2009/06/8/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx

Plus: http://blogs.msdn.com/b/maoni/archive/2007/05/15/64-bit-vs-32-bit.aspx

Mark Sowul
  • 10,244
  • 1
  • 45
  • 51
2

x64 processes have access to more instructions and more registers. By compiling for x86 vs Any CPU you give up the ability for the JIT compiler to use those instructions and registers (and more memory), typically resulting in a (small) performance penalty. But really, 99 times out of a hundred your users won't notice.

What they will notice is that your program doesn't work if you compile it for Any CPU because there is no 64bit OLE driver for dbf files. This format is not used as much any more, and so it wouldn't surprise me to learn that Microsoft has not written and has no plans to build the 64bit version.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
1

I cannot answer question No 1. but as for No 2 the answer is probably "it depends". Heavy mathematical operations (e.g. cryptography) can get a significant speed boost in 64 bit systems if implemented properly. And also you'll be able to address more memory (but that is probably not an issue if you're not using massive amounts of memory).

In other cases I have actually seen small slowdowns for 64-bit applications compared to building them as 32-bit applications (probably due to some overhead related to larger addresses).

Yhrn
  • 1,063
  • 7
  • 16