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 28 2019, 07:05 PM
Post#41



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


QUOTE
Using MyCon As New OleDb.OleDbConnection(My.Settings.AceTest)


When I reproduce the code given above, I get the error: "'AceTest' is not a member of MySettings". Error Code is BC30456

Go to the top of the page
 
Raas
post Oct 28 2019, 07:14 PM
Post#42



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


I just went through and verified that I had entered all of Albert's code correctly. I did. The error message shows "MySettings", but the code was entered properly as my.settings. I tried taking the 'dot' out of the code, but get a different error that way, so I have returned it to the original my.settings

Go to the top of the page
 
AlbertKallal
post Oct 29 2019, 02:30 AM
Post#43


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


Well, of course just like choosing variable names, it’s up to you to choose whatever you like for YOUR setting name.
I mean, for a name of something, I might use:

Me.FirstName

And you might use

Me.CustomerFirstName


One could just hard code the connection string, but I used the app settings and the connection string builder. I mean it just makes sense to put the connection string in “one” place as opposed to re-writing over and over in your code. And the bonus feature of using the app-settings is:
It is built into visual studio. (Always wish we had something like this in Access).

It has several kinds of “builders”.

So it has a connection string builder.

So it has a color builder. (so you could make some custom colors for your forms, and thus be able to “change” the color in one place, and all your forms would use that color).

So it has a font builder - all kinds of neat-o builder.

So, all kinds of “general” purpose settings can be placed into the application settings area.

So for example, you might want an application wide setting such as “Company” name that you display on all forms. Again, using the application settings is a good idea and tip (certainly not something you must do – but just a good idea).

However, if you read close my last post, I did give you the connection setting I used. And again, like a file name, table name etc? Well of course these things are really up to your choice. No more or less then whatever flavor of ice cream floats your boat. I can’t possible read your mind as to what names you choose for things.

To launch the VS “over all” application settings to allow you to make a connection setting (like AceTest, or AceZooZoo)

So after opening your project, then from the main menu, select project, and then usually near last option is properties.

This one:

And of course the “name” of your project will be whatever floats your boat (whatever name you used will appear – in MY CASE I just happened to use AceTest).

And then I choose the settings tab.

This one:



As you can see in above, I created two connection string settings.
One is called AceTest, and the other is AceZooZoo

I also added a string setting called CompanyName.

In fact, you find as a general rule, most settings really are just strings. There is NOTHING special about these values. Keep in mind that AFTER using the builder (see my comments later in this post), then when the builder closes, it just shoves the resulting string into the above text box. So the builder just "builds" you the setting, but you could just type in such settings without using the builder (but who has that kind of memory to remember the exact format).

So, in my code, I can now grab/use that setting in place of having to directly type in connection strings in code (yuk – if not double yuk!!!).

So, in my code, I could now use:

My.Settings.AceTest

Or

My.Settings.AceZooZoo

All the above does is grab the string value you have in the settings area above.

So, in code to display my company name setting, I could use:
CODE
MsgBox(My.Settings.CompanyName)


So, for example, my connection object line of code could be:

CODE
Using MyCon As New OleDb.OleDbConnection(My.Settings.AceTest)

Or perhaps we use the second one (since they ARE the same in this example)

Using MyCon As New OleDb.OleDbConnection(My.Settings.AceZooZoo)

Or perhaps we decide to suffer, and make for a long day, and use this:

Using MyCon As New OleDb.OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;DataSource=C:\test3\test44.accdb”)


Note how messy that last example suggestion was.

So you can “manually” type in the connection string right in your code. But as above shows, it certainly a lot less effort (and less ugly) to use the application wide “settings” feature in VS, and it also gives you a connection string builder to boot.

To launch the “builder”, note the [...] button that appears when you click or move your cursor into the “Value” column.

This one:


That “builder” is really much the same feature you see in access to launch extra options. So to launch the “builder” (in this case a connection string builder), then click on that [...] thingy/button that appears (the hand is pointing at it in above). As noted, Access also has this idea in lots of places. so that builder button ONLY appears if you click into that text box.

Make sure you select the combo box(s) before you try to use the builder.

So, after you type in say AceZooZoo, and select connection (first combo box), and then select Scope combo (Application), then now you move into the Value area box. You can click on the [...] builder button. But you can ALSO just type in the string also without using the builder. I certainly recommend playing with these settings.

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

Go to the top of the page
 
Raas
post Oct 29 2019, 01:14 PM
Post#44



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


Albert, you are a very patient man!

That last post cleared up a lot. I actually understood all of it, and it removed the latest error (as you knew it would).

However. It seems there's always a 'however' with this project: I now run the test and I get the same old error of "System.InvalidOperationException" 'The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.'

Yet, we have tested, and it's installed. It still shows up.

I'm curious. Which version of VS are you running that allows you to get no errors?

Also, I note that your system shows, next to 'Debug', that it's x86. Mine only shows "Any CPU". I'm running x64., but Any should mean ANY.

I have even created a project that has only one form, one button, and only code for that button. Of course, the code is that which you have so graciously supplied me in steps. There is nothing else in the project. I even named it AceTest. My Access database is 'LegalFees'. The table I use is 'tblLegalFee'. I'm only testing for two fields, as did you. They are Payee , and TransCount .
This post has been edited by Raas: Oct 29 2019, 01:14 PM
Go to the top of the page
 
AlbertKallal
post Oct 29 2019, 10:05 PM
Post#45


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


No, ANY does not really mean "any" the way you are thinking here.

It means that the program that "launches" YOUR program can be ANY, but we don't want that.

ANY does NOT mean that everything you have can be ignored and that ANY can work with ANYthing.

As noted, I usually "force" the project to x86, or x64.

You can't (and don't want) to use "any", since then you NEVER be sure what bit version of the project is going to be running as.

So, in your case, you want to be sure that your project is set to x64 bits.

ANY does mean "any", but that often means for the most part (and especially when launching + using visual studio, ANY will tend to choose out of the blue x64 or x32 bits, and you do NOT want this.
In fact, because you are launching your program from VS, then ANY will tend to result in your application running as x32.

So, if you using x64 ACE, then you can't leave this choice to ANY, since you can't be sure what bit version your software will launch as. the "ANY" choice is great say if other .net programs might launch YOUR program. "any" means just about anything, and that's not what we want.

ANY does not mean you don't care and don't have to worry about the setting. ANY really means that your program is likly to launch as "ANY" version it pleases, and if it launches as x32, then your code will not work.

So, in your case, we really can't use "any" as a choice. You have to force the choice here. If Access/ACE was a .net program, then yes, ANY would be fine. But Access is 30+ years old, and it not a .net program, so it can't know or use "ANY". So, we KNOW that you using access x64, so we better make sure we force the bit size of your .net program to also and ALWAYS run as x64.

It is not 100% clear if you testing + trying this with your project set to "any", but you MUST set and force you project to x64 bits.

The series of previous screen shots shows and goes about how you can create a x64 bit config. And you MUST run your application as x64, as ANY will not work in all cases, and in fact when running from Visual studio, the choice of "any" will not work at all.

So "any" don't mean it will work with "anything", but means you don't care what bit size the programs runs as. As noted, in most cases you don't care, but in this case we have to force how your application runs, since if we don't, when it attempts to use ACE, if ace don't match, it will not work

Try your application as x64 bits - review the previous post here where the steps were outlined to force and setup your application to ALWAYS runs as x64 bits.

ANY cpu setting simply cannot be used here and will not work.

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


Go to the top of the page
 
FrankRuperto
post Oct 29 2019, 10:23 PM
Post#46



Posts: 333
Joined: 21-September 14
From: Tampa Bay, Florida, USA


I always thought that if "Any CPU" is selected, the JustInTime compiler automatically detects and sets the bitness and the program execs, including x86 and x64 Access COM objects.
This post has been edited by FrankRuperto: Oct 29 2019, 11:20 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
AlbertKallal
post Oct 30 2019, 09:16 PM
Post#47


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


You are much correct.

But the problem is ONCE the program starts "one way" as x32 or x64, then it remains as such!

and during the development process, Visual Studio (VS) is a x32 bit program. So if you debug, develop, and test with any, then you going to get the resulting program running as x32.

So, ANY most certainly can "run" as x32, or x64, but it cannot change it mind ONCE it starts.

So, if you start a .net program as x32, then it can use other .net programs, or even libraries you referenced (and if they are set to any), then your main program, and any thing else you use can "switch" and run as the same bit size. As noted the term "switch" here is a really bad choice of words on my part. .net does not "switch" bit size, but is able to START as a given bit size and continue to run that way.

the above is all fine and dandy if you just using and running .net code (what we call managed code)

However, we are using ACE x64, and thus we simply have to prevent .net from starting as x32, and using the default "any" during debugging will in fact cause .net to start as x32.

However, if you choose x64, then even during testing and launching and starting from VS, you will be sure that you get a x64 bit running process.

So the "big" issue and problem here is that choosing ANY during the development process will usually result in a x32 bit running instance of your application. Of course choosing "any" will allow it to be called from x32 or x64 bit programs, but the key concpet is HOW the process starts. Once the .net starts running one way, it remains that way.

Bottom line:
DURING the development process, if you want a x64 bit version of the application to be used, you can't use ANY. You have to force this setting.

As noted, for most people, it really often don't matter because that .net code will run either way. However, when you introduce non .net code systems (such as Access/JET/ACE), then you can't leave this choice to the wind.

If Access was calling + using the .net code, then you can most certainly use "ANY" for the .net code. However, if the code is a COM object, then you have to register the COM object as both x32 and as x64 (you need TWO regasm.exe commands. I have tested this concept, and it does work). So you can setup and create .net code that can be consumed by access x32, or access x64.

However, if you going to launch .net first (as we are in this case), then we MUST make sure it starts as x64, else attempting to use ACE x64 will fail.

So in theory and practice, you are correct - .net code with ANY can run and on the fly start as x32, or x64 - but once it started one way, it can't flip to the other.

From VS, during testing and debugging, it will start as x32 if we choose x32, and it will also tend to start as x32 if we choose ANY. So, we have to force the issue and choose x64 bits.

Now, I suppose one could force start the application as x64 EVEN if the setting was ANY, and the way you would do this is to ensure that you launch the windows x64 bit command prompt and then launch the .net program. if we launch the x32 command line prompt, and then start the same progam, then it will run as x32.

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





Go to the top of the page
 
Raas
post Nov 4 2019, 06:43 PM
Post#48



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


Well …

I just spent four days going over all of these posts, digesting what I could. I broke them down into a step-by-step process, based on the posts by, mainly, Albert Kallal. I followed the instructions exactly, and I can't get an x86 template in the configuration manager. Without that, it would be impossible to create an x64 solution platform.

I've run the scripts, run everything presented. I can verify that ACE 64 bit is indeed, installed.

I even got desperate and went to Costco and bought a new computer. Installed Windows 10 pro, did all of the updates (that took time), then installed my Office 2019 (not subscription based), then installed Visual Studio 2019 and all of the components it allowed me to install. Then I started VS and a new project for a Windows Form. The first thing I did was to try to make a data connection (after doing all of the step-by-step instructions). I get the same error of "System.InvalidOperationException" 'The Microsoft.ACE.OLEDB.12.0 provider is not registered on the local machine.'

That's where we started with this situation.

I believe that Microsoft has a real problem that they haven't even tried to address yet.

If I'm doing something wrong, please don't just "point" me in a direction anymore. I've had weeks of that. This is one time I'm asking for exact complete information. Can someone please just write out the step-by-step instructions that will take care of the situation? I would be so grateful!

I've learned so much from Albert's posts, but now I can go no further, I'm afraid, without the full in-order instructions.

Thank you all!
Go to the top of the page
 
FrankRuperto
post Nov 5 2019, 01:00 AM
Post#49



Posts: 333
Joined: 21-September 14
From: Tampa Bay, Florida, USA


QUOTE
I even got desperate and went to Costco and bought a new computer...


wow don't despair lol, albert please rescue

QUOTE
The Microsoft.ACE.OLEDB.12.0 provider is not registered on the local machine.'


Visual Studio is only available as a 32-bit application. If you connect to Access from within Visual Studio, you must have a 32-bit version of ACE installed, it wont work with 64-bit ACE, period.
64-bit processes cannot load 32-bit DLLs, and vice versa. When a call is made to the ACE provider, the 32 bit process will attempt to locate a 32-bit DLL. If ACE is 64 bit, its DLLs are 64 bit, thus you get the above error.

My two cents


--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
Raas
post Nov 5 2019, 11:32 AM
Post#50



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


I have followed Albert's information to the letter, at least I think I have. I downloaded the 64 bit version of ACE. I tried to "force" VS to use an x64 bit configuration, piggybacking off from the x86 configuration, but VS 2019 isn't showing me an x86 template as is shown in Albert's information. So, I'm lost and running out of time.
I have done a lot of research and finally found some information (just this morning), from Microsoft that says that Office 2019 is distributed ONLY as a click-to-run installation and that MSI installation options are only available on servers, which, of course, I don't have and couldn't afford anyway.
Since I can only have a "permanent" version of Office 2019 that is still just a click-to-run version, and since VS 2019 is installed as an MSI installation, I'm being led to the conclusion that, since MSI and C2R won't communicate with each other, that Microsoft has screwed up and needs to correct this problem. VS 2019 is not worth anything as it pertains to communicating with their own Office 2019.
If I'm wrong, I'd be glad to have someone say so and show me how to get around this dilemma.
Go to the top of the page
 
AlbertKallal
post Nov 5 2019, 07:39 PM
Post#51


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


QUOTE
Visual Studio is only available as a 32-bit application. If you connect to Access from within Visual Studio, you must have a 32-bit version of ACE installed, it wont work with 64-bit ACE, period.


Well, sort of correct. The key conception is WITHIN VS. If you use the "test" connection during setting up of a connection to ACE WHILE in VS, then yes, it has to be x32 ACE. However, if I have only ACE x64, then during the setup, the test connection part during the setup of a connection will fail, but if I run (or debug) the application, it will run as x64 bits. So all you have to do is setup the connection, but SKIP hitting or using the test connection button. That you have/get during most connection setup dialogs and wizards in VS.

Again:
If you force the project to x64 bits and NOT use any, then you WILL get a x64 bit running instance of your application, and you can use ACE x64 as a result. I can double and triple check if you have to run as "release" as compared to debug mode - but this is not my understanding at this point in time.

Read my comments careful. if you use x86, or ANY - your .net program will start as x32 (because VS is x32)
However, if you force the issue and specify x64 bits in the config, then your application is launched as a x64 in-process application, and this will allow you to use ace x64.

I'm gong to double check the above. It is "possible" that you have to choose "release" as opposed to debug to force this issue, but this is not my understanding at this point in time.
R
Albert
Go to the top of the page
 
AlbertKallal
post Nov 5 2019, 11:35 PM
Post#52


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


QUOTE
and I can't get an x86 template in the configuration manager.


Over and over like a broken record, we MUST set this project to x64 bits. This whole discussion has centered on this issue.

The set of screen shots went step by step for this process in a previous post here.

Look at those steps again.

You should see this for the project settings:




If you don’t see or have the above, then this will not work. It is as simple as that.

I have attached a sample vb.net project. Unzip it to some folder.

Then from VS, go file->open project, and browse to the folder where you un-zipped the attached zip file.

You will find a ".sln" file to open.

You can then double click on the button in the sample form to open up the vb code editor.

You have to modify the code behind the button.

So change c:\VS\test44BE.accb to a known database on your computer.

And change the “table1” to a KNOWN table in that Access database.

At that point you can hit f5 to run. It should display the number of rows in that given table.

As noted, VERY much of the posts here have centered on the fact that if you fail to set your project to x64 bits, it simply not going to work.

Try the sample project I have attached. Modify the code in the sample for a known database and a known table in that database. The sample should just work fine.

Edit:
The code behind the button is this:
CODE
        Dim strCon As String

        strCon = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\VS\test44BE.accdb"

        Dim strSQL As String = "select * from table1"

        Dim MyCon As New OleDb.OleDbConnection(strCon)
        Dim DataRead As New OleDb.OleDbDataAdapter(strSQL, MyCon)

        Dim rstRecords As New DataTable

        DataRead.Fill(rstRecords)

        MsgBox("reocds in table = " & rstRecords.Rows.Count.ToString)


So in above, you need to change the database name/path in above (c:\VS\test44BE.accdb) to a known database on your computer.
and you need to also change the "table1" in above to a known table.


Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Attached File(s)
Attached File  WindowsApp2.zip ( 231.57K )Number of downloads: 1
 
Go to the top of the page
 
dmhzx
post Nov 6 2019, 10:41 AM
Post#53



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


A quick note to Albert:
Just to say how much I've learnt for all your posts here.
I'm currently attempting to get to grips with VB .Net after years of VBA experience, and you explanations of the 'bits' have been very interesting.

Thank you - You've been much more helpful than Microsoft's official .Net support, who after many attempts have finally admitted that the VB .Net folder browsing dialog does not work properly, but the C# one does. (Not expecting an answer on that new question, just using it as an example)
Go to the top of the page
 
AlbertKallal
post Nov 6 2019, 10:42 AM
Post#54


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


QUOTE
I'm gong to double check the above. It is "possible" that you have to choose "release" as opposed to debug to force this issue, but this is not my understanding at this point in time.


I have checked this. So, no problem, both release and debug work, and if the project is set to x64 bits, then your project runs as x64. I spooled up a vm on my laptop. Installed VS and ACE x64 redist. And again, if I run as x32, or as ANY, it fails exactly as i predicted. And if I run and start as x64 bits then it works fine.

So, everything I stated, claimed, hinted, suggested, implied and flat out claimed in this thread is a 100% correct. It makes sense, since I have several .net projects in which I am using x64 bit versions of code. One being the .net Ghost script library. I am running and using asp.net + vb.net. The web server runs as x64 bits, and if my project is set to x32 bits, it fails.

So, all is well, all is EXACT as I stated here.

The SIMPLE bottom line (and what I stated and suggested here OVER AND OVER)

Set your project as ACE x64 bits to use ACE x64.

R
Albert
Go to the top of the page
 
AlbertKallal
post Nov 7 2019, 03:10 PM
Post#55


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


QUOTE
after many attempts have finally admitted that the VB .Net folder browsing dialog does not work properly, but the C# one does.


Well, I am not sure what you “mean” by not working?

We should try and be fair about “some” issue here. I mean, I do a lot of .net work, and when Access comes up, it often it gets a bad rap as to how supposed “bad” Access is, or how it is some “toy”.

Access is not so bad and I often have to defend it in public. Many simply choose to un-fairly say bad things about Access, and that tends to be just people making un-fair and un-warranted judgement s about something they know little about.

No big deal if something don’t work for you, but it is a VERY DIFFERENT matter to make a general public claim about some feature or part of .net that is considered to be broken.
So in regards to say x64 bit support in .net (and use with ACE), or that of folder or file browsing in .net? We owe the public a basic and fair shake on these issues, and it’s only fair we bear fair witness and testimony on these issues, else we do the Access (or .net) community a GREAT disservice here.

I attached a folder browser, and file browser example as a project in .net.

It has a form with two buttons like this:



The top one does a folder browse.

It uses this code:

CODE
        Using MyFolderGet As New FolderBrowserDialog
            If MyFolderGet.ShowDialog = DialogResult.OK Then
                Me.TextBox1.Text = MyFolderGet.SelectedPath
            End If
        End Using



The second button does a file browse.

And code to select a file is:

CODE
      Using MyFileGet As New OpenFileDialog

            If MyFileGet.ShowDialog() = DialogResult.OK Then
                Me.TextBox2.Text = MyFileGet.FileName
            End If

     End Using


So it’s about 2-3 lines of code to folder browse or about 2-3 lines of code to file browse. .net.

I would in fact say .net is rather good in this area, and the above shows how amazing EASY this is to do in .net. It not much code at all.

Keep in mind that c# and vb.net SHARE the system CLR (common language run-time system). At this point, BOTH in fact use the SAME compiler!

So c# and vb.net really work and feed from the same set of code systems. You can in fact take a c# project and include or reference that project from vb.net and use that c# code. And the reverse is also possible!

In other words, if something don’t work in c#, then it unlikely to work in vb.net. And the reverse is true.

So speed of code execution, the amount of memory used, and how c# works or vb.net works is really the same. And this is true in terms of features between the two systems. (A very few tiny insignificant differences in feature sets exits exist between c# and vb.net. They are as close to each other as you can get in terms of "how" they will work for two different languages (because they share the same runtimes, and same common language engines).

You can try the sample zip project attached. Just un-zip to a file and then from VS choose open project, and open the .sln file in the un-zipped folder. Now just hit F5 to run, and you can see the folder, and file browsing code in action. They both work rather well.

So, “some” issue might exist in c# vs vb.net, or the reverse, but I not aware of any issues in regards to file or folder browsing.


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


Attached File(s)
Attached File  FileBrowse.zip ( 951.31K )Number of downloads: 1
 
Go to the top of the page
 
FrankRuperto
post Nov 7 2019, 03:56 PM
Post#56



Posts: 333
Joined: 21-September 14
From: Tampa Bay, Florida, USA


@dmhzx

The following vb.net code, developed by Albert, is a console project (i.e. formless) for copying files from a source folder to a destination folder.
Although there's no forms involved in this project, it works fine and is also being consumed by Access via COM interop.


CODE
Imports Microsoft.VisualBasic.FileIO
Imports System.Environment
Module Module1

    Public Sub Main()

        If GetCommandLineArgs().Count <> 3 Then
            Console.WriteLine("Missing from or to folder or too many values")
            Exit Sub
        End If

        Dim strSourceFolder As String = GetCommandLineArgs(1)
        Dim strDestinationFolder As String = GetCommandLineArgs(2)

        My.Computer.FileSystem.CopyDirectory(strSourceFolder, strDestinationFolder, UIOption.AllDialogs)

    End Sub

End Module



The Access VBA code:

CODE
Sub MyCopy()

   Dim F As New MyFolderCopy.clsFolder
  
   Dim bOk  As Boolean
      
   bOk = F.Copy("S:\Databases\Pawnshop\Data", "F:\")
      
End Sub

This post has been edited by FrankRuperto: Nov 7 2019, 03:58 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
FrankRuperto
post Nov 7 2019, 11:39 PM
Post#57



Posts: 333
Joined: 21-September 14
From: Tampa Bay, Florida, USA


@Raas

The vb.net FolderCopy project in my previous post was compiled into an x86 exe because it is being consumed by an x86 Access 2010 msi app. I have intentionally avoided using x64 and ClickToRun versions of Office for obvoius reasons. Are you required to use x64 Office? Unfortunately MS deprecated msi in Office 2019 and I'm afraid x86 is also going to disappear in the next Office version , while the rest of the components like VS and 3rd party addons continue to be x86.
This post has been edited by FrankRuperto: Nov 7 2019, 11:50 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
AlbertKallal
post Nov 8 2019, 02:20 AM
Post#58


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


QUOTE
This is one time I'm asking for exact complete information. Can someone please just write out the step-by-step instructions that will take care of the situation? I would be so grateful!


I can do one better.

Simply download the accesstest zip folder attached to this post. It has two .exe files

AccessTest32.exe to try access as x32 bits
AccessTest64.exe to try access as x64 bits.

What is REALLY cool here? Just unizip the above, and click on either one of the above .exe files.
They are SUPER small!!! - no install, no nothing, no coding, no guessing!!!

Just click on them to run.

They are only 20kb in size (yes, you read that correct!!!). (that's smaller then this web page!!!!).
In fact, the stand alone .exe files are LESS in size then the picture I have in this post!

The reason of course is they are .net .exe files. So, everything they use is in the .net run times.

When you click on this .exe file, you get this:



So, if you want to test for Access x32 bits, then try AccessTest32.exe. And if you want to try for x64 bits, then try AccessTest64.exe

ALL you have to do is unzip the attached zip file to a folder. And then click on either one. Really as easy as can be.

The dialog simply lets you browse to (file select) a accdb file. Then hit the open database file. Now, all of the tables should appear in the combo box.

If the table has data, then the grid area in above will display the data.

So, in effect it is a simple access database browser. You select database file. Then hit Open database button. The combo box should fill with the tables from that database.

So, select a database table in the combo box, and the grid will display that table!!!


If neither work, then simply install the ACE data engine found here:

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


So, even if you are running a CTR (office 365) version, installing the above ACE data engine should mean you are up and running, and off to the races.

You are given two choices when you download the ACE engine, x64, or x86 - make sure you choose the right one.

Enjoy - and good luck!
R
Albert
Attached File(s)
Attached File  AccessTest.zip ( 16.88K )Number of downloads: 3
 
Go to the top of the page
 
isladogs
post Nov 8 2019, 05:18 PM
Post#59


UtterAccess VIP
Posts: 1,879
Joined: 4-June 18
From: Somerset, UK


Albert
I just replied then deleted my response by mistake. Oops!
Trying again...

I've not followed this lengthy thread in detail but downloaded your zip file from the previous reply.
The utility is indeed very impressive, especially considering its tiny file size.

I tested it on a number of Access apps and it worked perfectly except for password protected files and those with specific start-up conditions such as open exclusive.

I created something similar in Access partly in response to a question by UA member payfast8898. See List external tables
In that example I was focusing on the table properties rather than the contents. However I've also done that for my own use

I hope I'm not being too presumptuous but if you are willing to do any/all of the following your utility would be even better ...in fact excellent
1. Add ACCDE files to the browse window
2. Allow users to enter a password where needed
3. Ditto for other command line switches such as /excl
4. Change the tables combo to a listbox
5. Add table record count to the form

TIA if you are willing to do those changes

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
AlbertKallal
post Nov 9 2019, 01:32 AM
Post#60


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


QUOTE
The utility is indeed very impressive, especially considering its tiny file size.


It really is stunning - if there is one really cool thing about .net, it this stupid crazy small file and a stand alone .exe to boot!

You can place this on a USB jump drive and NOT even install it. You can even open and launch this from the USB jump drive. ZERO install!

A rather handy dandy tool, and no access need be installed for it to work! (but for accDB, then at least ACE need be installed).
I'm going to look into seeing what possible ideas would allow me to include ACE for this.

QUOTE
I hope I'm not being too presumptuous but if you are willing to do any/all of the following your utility


Great ideas - very little work to add. Done!!!!

REALLY like your suggest for a list box.

Now you can just tap (one click) on a table – and it displays.

I also anchored the list box and grid display. So now if you have a large screen, and max (or re-size) the form, then the table list and grid “expand” to full screen size. (so nice on small or large monitors).

I also added the choice to use JET or ACE. Of course if you run the x64 version, then JET will never work. But there not “two” versions of this code. I only compile the ONE program two times.

Here is what the screen now looks like:



Last but not least? Well, it still only 23kb. Still laughing my pants on this size issue!

It is a really nice way to browse and view access files. And for browsing Access files on say “run time only” machines, or even machines without Access it is ideal.
(they will have JET). And hopefully ACE - but if not, the install of ACE is certainly MUCH smaller then installing Access run time. I going to put ACE (installer) on my jump drive too!

I still have both a x32 and x64 bit version included. It “is” possible to only have one version that works for both bit sizes, but the “steps” to have a user launch correctly is likely too much of a hassle.


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


Attached File(s)
Attached File  AccessLook.zip ( 20.51K )Number of downloads: 3
 
Go to the top of the page
 
4 Pages V < 1 2 3 4 >


Custom Search


RSSSearch   Top   Lo-Fi    7th December 2019 - 07:09 PM