UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
4 Pages V < 1 2 3 4 >  (Go to first unread post)
   Reply to this topicStart new topic
> Visual Studio 2019    
 
   
Raas
post Oct 10 2019, 01:32 PM
Post#21



Posts: 639
Joined: 27-January 07
From: Northern Arizona


I decided to post the exact complete message I get when trying to install the 32 bit ACE database engine 2016 provider in my "new" installation. I think it shows that MS has made a gigantic error by not having a 64 bit version of VS.

---------------
Heading: Microsoft Access database engine 2016 (English) Setup

Message:
You cannot install the 32-bit version of Microsoft Access Database Engine 2016 because you currently have 64-bit Office products installed. If you want to install 32-bit Microsoft Access Database Engine 2016, you will first need to remove the 64-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 32-bit version of Microsoft Access Database Engine 2016:
Office 16 Click-to-Run Extensibility Component.

Then another message will come up: Installation ended prematurely because of an error.

------------

Well, I don't have Office 16 on my computer. I can't run 32 bit and 64 bit MS products concurrently.

Go to the top of the page
 
Phil_cattivocara...
post Oct 10 2019, 03:13 PM
Post#22



Posts: 368
Joined: 2-April 18



QUOTE (Raas)
Message:
You cannot install the 32-bit version of Microsoft Access Database Engine 2016 because you currently have 64-bit Office products installed. If you want to install 32-bit Microsoft Access Database Engine 2016, you will first need to remove the 64-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 32-bit version of Microsoft Access Database Engine 2016:
Office 16 Click-to-Run Extensibility Component.

Did you read the link I suggested in my #15? You will find how I solved it.


--------------------
Please forgive in advance my horrible English.
Go to the top of the page
 
Raas
post Oct 10 2019, 05:18 PM
Post#23



Posts: 639
Joined: 27-January 07
From: Northern Arizona


I did, and tried that. Same error.
All I get when trying to install is a blank command prompt screen for about 2 to 3 seconds, and then revert to the original screen.

I'll go to another computer when I get home from work and try again with that one.

Thanks for trying again!
This post has been edited by Raas: Oct 10 2019, 05:21 PM
Go to the top of the page
 
AlbertKallal
post Oct 11 2019, 03:17 AM
Post#24


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


Ok, let’s clear this up.

As noted, the 2019 CTR simply does not install + expose the ACE data engine for other external programs. While not important, the “idea” here is MS is starting to compartmentalise their programs. (they are becoming app-v packages) The idea is that install say Access 2019 will not affect other programs and “play nice”. In effect Access (and most of office) is marching towards the day when you don’t even have to install the program – you just run an .exe. In effect, this has been a dream of the access community for 20+ years.

So, CTR technology is not 100% “there” yet in terms of stand alone running of office programs. (and it not that the technology is lacking, but they are “moving” in this direction).

So MS installed stubs to “talk” to these CTR versions of office.

Those stubs are “outside” of the CTR system. So 2010, 2013, 2016 all installed this “stubs” to help “regular” folks use ACE and Access via “COM” interaces. But we are fast moving away from that model.

The future means you will NOT install software anymore!

So, what this means?

We WILL see the day when we don’t actually have to install Access anymore!!! (it will be a simple .exe file and a single file at that!!!). And when this occurs, then you be able to run multiple editions of Access, and all without having to install them!!!

So for 2016, and 2013 (CTR) they “did” register a set of dll’s to talk “inside” of the virtual applation. However, this is a messy affair, and was ONLY a stop gap approach on Micrsoofts part.

And wonders of wonders? It looks like for 2019, they don’t do this anymore (they avoid this mess).

Welcom to the future!

As for the bit size issue? Well, we had x32 and x64 verisons of Access since 2010. Again, you can’t mix the SAME version.

Now, I could make a “long” post here I am so famous for, and explain HOW 2010, 2013 and 2016 “CTR” actually ALSO allowed external programs (like VB6, vb.net) to use the ACE engine.

With 2019, it quite clear that not the case (but I been expecting this for 10 years!).

So, in your case?

Install the ACE re-dist package from here:

https://www.microsoft.com/en-in/download/de...s.aspx?id=13255


And make sure you install the x64 version!!!

And, this means you BETTER force your .net project to x64 bits!

You see, for 30+ years, “JET” shipped with windows and for that 30 years, it been x32 bits. Yet you want to run x64 bits!

So, installing the re-dist for ACE is your best bet.

And do keep in mind that you have to force your .net project to x64 bits.

And I suppose, if you have x32 2010 (runtime or otherwise) installed, then un-isntall it, and go with the ACE re-dist.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Go to the top of the page
 
Raas
post Oct 11 2019, 10:20 AM
Post#25



Posts: 639
Joined: 27-January 07
From: Northern Arizona


Thank you, Albert!

That sheds a lot of light on why VS 2019 and Office 2019 don't talk to each other nicely. At least I know I'm not completely crazy now.

It does leave one unanswered question though: You said to make sure I FORCED my applications/projects to be 64 bit. I do all of my Access databases as 64 bit. I don't know of any way to force a VS project to 64 bit unless the connection to the 64 bit database provider does so. What am I possibly missing, or am I even missing anything now?

Thanks again. Your lengthy explanations are truly appreciated.

Go to the top of the page
 
AlbertKallal
post Oct 11 2019, 01:33 PM
Post#26


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


Forcing the bit size of your .net projects?

Well, if you ever built say a “COM” object to extend Access (use + call vb.net code from Access), you will fast realize that such code you call + use + consume HAS to be the same bit size as Access you are running.

So, you can’t for example in Access x32 use:

Set AutoCad = CreateObject("AutoCad.UI")

The above will fail because you using Access x32, but AutoCad is x64 bits. Now of course since the “dawn” of the personal computer age, we had to deal with the change from 8 bits to 16 bits, to 16 bits to x32 bits to x64 bits.

Now it is possible you are somewhat new to computers in general or say not aware we had an x64 and x32 bit versions of Access for 10 years now.

But when it comes to using the say the common dialogs “tree view” control, or the Access ActiveX calendar control? Well for 10 years now, we seen truckloads of questions + answers on UA.

And of course your API calls to windows often have to be changed or upgraded to with x64 bits.

And the answer is since no x64 bit tree view or x64 ActiveX calendar drop in exists, then if you jump to x64 access, you can’t use that tree view control anymore. And the same goes for any other add-ins such as PDF viewers etc.

Since we “all know” and realize that JET is x32 bits, then obviously if we going to use JET from VB6, FoxPro, vb.net, c++ (and insert EVERY developer tool on the planet here!!), then of course that development tool MUST and WILL have to match the bit size of the program in question (JET x32).

As noted, this basic concept goes all the way back to the first time one hit the power on button on an Apple II, or a brand new cool surface pro.

So, when creating a project, in “most” development platforms you tend to “just use” the product, and you quite much forced to deal with and be “stuck” with the bit size of that development platform. As noted, .net is really nice in this regards, since .net code can call + consume other .net code of any bit size, and it can deal with this issue because .net has what we call a “JIT”. (Just in time compiler). JITS are an ASTOUNDING technology change in our industry. The result is you can write in HTML + JavaScript for your Android phone. Google has spent so much R&D on their Android JIT that such code is not only platform neutral, but such scripting type of code actually runs as fast as raw c++ or even BETTER on your android phone! In other words, some [censored] scripting language (slow) now runs as fast as hand coded optimised c++ compiled to a native ARM CPU on your phone!

And we seeing web browsers do the same thing!! Now, I want to keep on writing about what this means for our industry (but the ramifications are so huge it not even funny – but we save this talk for another day!!!). Anyone reading this should be able to figure out what this means (and it going to change software development in such a huge way it is not even funny. If anyone wonders what this means – just ask, and I’ll explain.

Anyway, back to the issue at hand:
So, if you install Access 2010 x32, and then say Outlook 2013 x64 bits?

Well, Access then cannot “automate” or “consume” Outlook with:

Set MyOutLook = New OutLook.Application ‘ early bind
Dim MyOutLook as New Outlook.Applicaton

Dim MyOutLook as object
Set MyOutLook = CreateObject("OutLook.Application")

So in above, we would be asking an x32 bit program to interface and talk to and “create” an x32 bit “instance” of outlook, but “if” Outlook is x64 bits. That will NOT work!

This is really no different than for the past 10 years seeing stories on UA about how some company decided to use Access x64 bits. Not the end of the world, but if they were using say Tree View (ActiveX), or say the common “calendar” control (ActiveX) for Access, they would find that those external ActiveX add-ins do NOT work anymore.

Again, this is because there is not for example an x64 bit version of the Tree View control. You thus can’t use such ActiveX controls and add-ins with Access x64, because these add-ns and external controls were written as x32 bit programs. (And they are un-managed code (which means non .net, which in turn means such code can’t do that “trick” to run as x32 or x64).

So, you are simply NOT allowed to call + use + consume x64 bit software if you are running Access x32.

Now the SAME applies when using Visual Studio. However, Visual Studio allows you to “target” the bit size due to .net ability to change like those cool lizards that change color!

So, you can in Visual Studio choose x32 (it called x86) or you can choose x64 bits for the final output of your compiled project.

And you can also choose “any CPU”. This allows both x32 and x64 bit .net code to consume the SAME output/compiled .net application. How this works is VERY interesting, but suffice to say WHEN .net code calls other .net code libraries (such as any project you create in .net), you can thus “set” the bit size to “automatic” or what is called “any CPU”. And .net can do that cool flipping trick for you (that magic JIT is the key).

However, Access, (and office) is NOT what we called managed code (managed code = .net code).

So:
Managed code = .net code.

Non managed code = c++, or systems without a JIT. (Like office programs, VB6, FoxPro, Access VBA etc.)


So what about Access calling + using .net code?

Well, for Access to call + consume .net code, then you have to “register” the .net class or object (and DURING that setup and registering process you will ahead of time choose x32, or x64 bits to “register” that COM/ActiveX .net object. You then can use CreateObject () in Access VBA to call + use that .net code.
In other words, when unmanaged code (Access) called managed code (.net), then that “automatic” on the fly bit size switching that is part of .net CAN NOT occur. You must choose ahead of time!

So the “automatic” bit size flipping feature of .net can ONLY work with .net to .net calls.

So, for Access to call + use .net code, then you have to specific set up the Visual studio project as x32 or x64. (But more important actually register the .net project to run/work as x32 or x64 ahead of time).

What about the reverse?
(Which is YOUR case!)

.net calling + using “non managed” code.

Well, once again, the non managed code is going to be frozen/fixed as x32 or x64 (non managed code cannot flip bit size like .net can).

Keep in mind that this “bit size” flip in .net does NOT occurring during running. Either your .net starts as x32 (and will stay running as x32), or it will start as x64 bits, and stay during running as x64.

So, in .net, if we use JET, then we KNOW for the last 30 years of Access, JET and Access has always been x32 bits.

So not only MUST we run our .net project as x32, but if JET works then we can conclude by logical thinking that our .net project MUST be running as x32, else we could not use the JET database!! And we can then by logic conclude that our .net code MUST have started running as x32!!!

However, to use ACE? Well two versions exist. And to use x64 ACE, we BETTER force and start our .net application as x64 bits.

So, we have this dialog in VS:




Note the setting in visual studio for x86 or “any”.

But if we choose configuration manager, then we can set (force) the .net project to run and be as x64 bits. (Just use new config, and use x86 as a template choice).

The dialog when launched and you create “new” config, you get this:



So, now the .net project is set (forced) to always be x64 bits. We need to do this if we going to use ACE x64. (Because this will force .net to run as x64 bits from the start, and that means it can call access x64 (ACE).

So, in .net land, when I say to run and set your project (force it) as x64 bits, it means to use the configuration manager for .net and “choose” + “force” the issue in place of leaving this setting as to how the wind is blowing that day.

But all in all, kind in mind, around the corner, we not likely to deal in installing software in the future – it will become a thing of the past! JIT technology, and combined with app-v will result in you just “using” software – kind of how like the web works!


Regards
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Go to the top of the page
 
Raas
post Oct 12 2019, 10:04 AM
Post#27



Posts: 639
Joined: 27-January 07
From: Northern Arizona


Seems to confirm that Visual Studio 2019 won't connect with Access 2019 64 bit since Visual Studio only comes as 32 bit.

Visual Basic through Visual Studio will give me programming features that VBA won't I need it, but I can see it won't happen. Of course, VBA gives me features that VB doesn't, but as you all know, I'm still very slowly and patiently learning VBA.

If Microsoft ever gives use the connection from VS to 2019 to Access 2019 64 bit, I'd love to do it and know how, but based on Albert's postings, that isn't going to happen.

Sounds like we are either going to have to be subscription based or nothing. So … nothing it will be. Time to check out what Apple and Linux have to offer. Probably not much.

Albert has been looking forward to this day for many years, but then he is a lot further advanced in knowledge than I am, so he can use the technology. I can't.

I'll just go into the University on Monday and tell them I can't teach VS 2019 in conjunction with connecting to Access 2019 64 bit. That seems to be the answer I'm getting.

Thanks to all, anyway. Thank you Albert for the lengthy discussions that led to this decision.
Go to the top of the page
 
Raas
post Oct 12 2019, 12:24 PM
Post#28



Posts: 639
Joined: 27-January 07
From: Northern Arizona


Sorry for this, but I just can't give up like that.

I've followed Albert's latest post as best as I can. He goes to the configuration manager and gets a drop-down that has "Any CPU", "x86", and "Configuration Manager". I do not have that. Her is what I see instead:

"Any Cpu", and "Configuration Manager".

I go to Configuration Manger and I don't have the x64 platform to work with. All I get is "Any Cpu', and the drop-down is <new...> and <edit...>

Not sure how to get the x64 platform into my Visual Studio 2019. I have ACE 64 bit installed, and, of course, the default Jet 32 bit.

I know I must be missing something in Albert's post, but what I don't know.

--------------Now, how does Albert paste screen shots into his posts? I'd send some shots of what I have if I knew how. I use Snagit to capture my clipboard shots, but they won't paste. I've tried the MS Print Screen as well. -----------------


Go to the top of the page
 
GroverParkGeorge
post Oct 12 2019, 01:33 PM
Post#29


UA Admin
Posts: 36,029
Joined: 20-June 02
From: Newcastle, WA


Re: imagesAttached File  attachimage.PNG ( 19.33K )Number of downloads: 0

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
GroverParkGeorge
post Oct 12 2019, 01:35 PM
Post#30


UA Admin
Posts: 36,029
Joined: 20-June 02
From: Newcastle, WA


Or you can use the upload function:
Attached File  uploadimage.PNG ( 47.02K )Number of downloads: 0

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
AlbertKallal
post Oct 12 2019, 02:40 PM
Post#31


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


A few things:

When I spoke of that “near” future, the context was not having to install programs on your computer, but just having to “run” them. That is a MASSIVE different context and issue than that of being able to use x64 ACE with VS – which of course is MUCH the whole reason for my post.

Of course you can!

I stated, hinted, implied, demonstrated to GREAT lengths that .net is not only able to work with x64 bit code, but has special features that makes this whole process VERY easy. And that includes ACE x64.

Why would I spend so much time explain things here and not just say this can’t work?

Just the logic of this post, and the length of this post SHOULD suggest that this setup can work! You should “assume” this can work based on just the length of the information even if you did not grasp what it means!

Anyway, no worries!

To summarize ALL of the above?

You have to get x64 ACE installed
You have to set and force your VS project to x64
(That is ALL you really need to know).


QUOTE
Not sure how to get the x64 platform into my Visual Studio 2019


Ok, I did hint and suggest how to do this.

QUOTE
Albert wrote:
Just use new config, and use x86 as a template choice).


Well, you actually not get “x86”, but you get “any CPU” (so my bad!!)

Anyway, from this dialog, choose <New>





You then get this



You can usually just hit “ok”

From above, make sure the first box is x64 (quite sure it defaults to that choice).

So, just hit “ok”.

The “copy” settings from “any cpu” is just that – it copies a existing setup/template ,and AFTER you copy that setup, you are allowed to edit that setup (but the x64 setting in the top combo is already selected for you)
.
After ok, you get this:




And now note that you now have “two” configurations!

Eg this:



(in above, I have 3 choices, since I during testing also added a x86 config – you likely only see 2). I create a “lot” of .net code that is called from access, so I often force my projects to x86.

Anyway, now that you have two choices “any CPU” and “x64”.

It should be now x64, but if the box in the main VS shows “any”, then you should be able to select and set x64 as a choice from the drop down.

I can’t remember if “setting” to x32, or x64 necessary “restricts” your possible choices when setting up a connection string (I think it does, but not sure – can’t remember).

However, once you do create the connection, and run, then it will fail if you choose any cpu, or x86.

But, if you choose and force the issue as x64, then you should be able to use ACE x64.

Good luck!

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
Raas
post Oct 12 2019, 05:01 PM
Post#32



Posts: 639
Joined: 27-January 07
From: Northern Arizona


OK. I realize I don't totally understand. I did read all of Albert's posts and understood much of it. The last post was very helpful. However, here is the sequence I just went through: Attached Word Document.




Attached File(s)
Attached File  Steps.zip ( 161.46K )Number of downloads: 2
 
Go to the top of the page
 
AlbertKallal
post Oct 12 2019, 06:41 PM
Post#33


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


As I stated, I don't think DURING configuration you are restricted to selecting ACE, but KEEP in mind that Visual Studio is a x32 bit program.

So, in theory based on what we all learned from my post (hopefully), then the Test connection button can't work. You have to actually run the code to test the connection.

Keep in mind that Visual Studio is NOT managed code (that's is all you need to know, the rest can be deduced by logic).

So, based on what we know?

You should be able to setup a connection, but testing such connections from a x32 bit program (say like Visual Studio) can't work.

It still possible that your ACE or some other issues exists, but based on theory (since I never attempted this), I have to assume that test connection can't work, but running some code as x64 should work.

Of course if you have both x32 and x64 Access installed, then test connection should be able to work for both x32 and x64.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Go to the top of the page
 
Raas
post Oct 12 2019, 07:32 PM
Post#34



Posts: 639
Joined: 27-January 07
From: Northern Arizona


All of you: I apologize for wasting your time. Albert in particular has been extremely patient and kind in his posts and responses. I understand about 80% of what he posts. It's obvious that he has knowledge, expertise, and experience that far surpasses anything I have.
I would be happy to write the code Albert talked about, if I knew how. I don't. I don't know where to write the code. I don't know what code to write or even what the code is. I assume it's code to create a connection to the Access database. If I knew how to do that, I would have done so.

I have learned a lot from this frustrating process of getting nowhere. What I have learned most is that I don't know what I don't know, and I don't know how to learn it.

So, unless someone is willing to do a step-by-step posting of the code (and where it goes in VB) for creating a connection, then I can only assume that with VS 2019 and Access 2019 64 bit, it can't be done, and as GPG stated way back, he and I hope that MS didn't do that to us.

As Albert stated in his latest post,
QUOTE
It still possible that your ACE or some other issues exists, but based on theory (since I never attempted this), I have to assume that test connection can't work, but running some code as x64 should work.
I'm getting the impression that all of the "fixes" so far have pertained to the VS and Access that is running on your own computers, and so far no one is running VS 2019 and Access 2019 64 bit, but earlier versions of both, and as Albert pointed out in his first posts, VS 2019 has changed the game.

Again, you have all been kind to me through this process and I appreciate it, more than any of you could ever imagine.

Go to the top of the page
 
Raas
post Oct 13 2019, 07:11 PM
Post#35



Posts: 639
Joined: 27-January 07
From: Northern Arizona


I guess that's it. I have researched 7 different VS texts and finally found an obscure reference to creating a connection in code. So I entered the following in the form load event. It doesn't throw an error, but it also doesn't actually make a connection.
Dim strPath As String = "Provider=Microsoft.ACE.OLEDB.12.0 ;" & "Data Ssource = E:\DGR VB Solutions\64Bit\bin\Debug\LegalFees.accdb"Dim newPath As New OleDb.OleDbDataAdapter(strSQL, strPath)
Try to connect to a database and I get the same "not registered" error.
I guess that's it.

Go to the top of the page
 
AlbertKallal
post Oct 15 2019, 07:17 PM
Post#36


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


Ok, it still not 100% sure/clear that you ever did get ACE installed, or in fact what version you installed?
However, try downloading the attached small little script file.

And run it!

When you click on accesstest.vbs it will run as x64 bits.

If it can’t create an instance of ACE, then ACE is not installed correctly.

And, if you want, you can try running the script as x32 bits.
(not required, but it is a good test!)

To run as x64, just click on the file from windows explore


To run as x32, you have to tap windows key, and type in:

%windir%\SysWOW64\cmd.exe

Now run the script
Cscript path to accesstest.vbs

Eg:

cscript c:\test3\accesstest.vbs

So, download the file. Un-zip, and run it. It will tell you if it can create an instance of ACE.

The code inside is simple:
CODE
if Instr(WScript.FullName,"SysWOW64") = 0 then
   msgbox "about to start script - this is running x64 bits -->" & WScript.FullName
else
   msgbox "about to start sript - this is running x32 bits -->" & WScript.FullName
End if
s = "C:\test3\test44.accdb"
on error resume next
Set acc = CreateObject("DAO.DBEngine.120")
if err.number = 0 then
   msgbox "create data engine 2007 (12) is good"
else
   msgbox "Ace 12 NOT FOUND!"
end if
msgbox "done CHECK"


And you could just cut + paste the above into notepad. And then rename the extension from .txt to .vbs and run that (that’s how I created this vbs script).

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada


Attached File(s)
Attached File  accesstest.zip ( 395bytes )Number of downloads: 3
 
Go to the top of the page
 
Raas
post Oct 24 2019, 08:07 PM
Post#37



Posts: 639
Joined: 27-January 07
From: Northern Arizona


Took me a while. I've had to attend meaningless conventions and just got back to look at this latest post last night.
I ran the script. The messages I get are as follows:
"create data engine 2007 (12) is good"
Then after clicking OK:
"done CHECK".
So, I'm assuming I have ACE for 64 bit installed.
Go to the top of the page
 
Raas
post Oct 24 2019, 09:52 PM
Post#38



Posts: 639
Joined: 27-January 07
From: Northern Arizona


I just noticed that I forgot to let you know that the script said it was running 64 bit.I wouldn't think it would make any difference, but FYI, I run ADO, not DAO.

This post has been edited by Raas: Oct 24 2019, 09:53 PM
Go to the top of the page
 
dmhzx
post Oct 25 2019, 02:20 AM
Post#39



Posts: 7,112
Joined: 22-December 10
From: England


Off topic slightly:

I have also posted a question on that Forum, and have had some response . - All of it useless.

Go to the top of the page
 
AlbertKallal
post Oct 25 2019, 06:55 PM
Post#40


UtterAccess VIP
Posts: 2,874
Joined: 12-April 07
From: Edmonton, Alberta Canada


Excellent.

All that script does is create a instance of the ACE (and DAO) object.

If the script could not work, then ADO is out of the question also!!!

So, we may not be 100% across this bridge, but it is VERY likely that if ACE x64 bits is working as that script suggests then we have a VERY good chance that we can now attempt to build a connection sting in the “settings” part of say a test application. So, all we know that ACE x64 is installed. It should means that ado should also work. So, we basic just determined if the lamp has electricity here and can now try a light bulb!


As noted, while in the project settings, you can use the connection string builder.

It should be able to build you a working connection,
BUT AS NOTED IN ABOVE POSTS YOU CANNOT USE THE TEST connection option in Visual Studio.

The above is due to VS being x32 bits while you develop software, but the compiled code can "build" and "compile" to x64 bits (which is YOUR case!!!!).

So the Editor and builder and connection string builder in VS is all x32 bits.


So, VS can’t test the connection, but it can build one for you.
You ONLY will be able to test if the connection works by running your code.

Don’t forget when building the connection string to change from JET to Ace.

Some code like this placed behind a button on a form would be a nice test:

CODE
        Dim rstData As New DataTable

        Using MyCon As New OleDb.OleDbConnection(My.Settings.AceTest)
            Dim daRead As New OleDb.OleDbDataAdapter("select * from tblHotels", MyCon)
            daRead.Fill(rstData)
            With rstData
                If rstData.Rows.Count = 0 Then
                    MsgBox("No data found")
                Else
                    MsgBox("Rows of data found = " & .Rows.Count & vbCrLf &
                       "First row of data: HotelName = " & .Rows(0).Item("HotelName") & vbCrLf &
                       "Pk ID (first row) = " & .Rows(0).Item("ID"))
                End If
            End With

        End Using


I will also point out that the connection builder for the above created this:
CODE
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\test3\test44.accdb


So, your connection string should also look quite much the same (take a quick look at what the resulting connection looks like). would also test open the database if you have Access intalled,, look at a given table, and if all is well, then exit access and try your VS project.


Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
 
4 Pages V < 1 2 3 4 >


Custom Search


RSSSearch   Top   Lo-Fi    14th November 2019 - 07:03 AM