My application is built to scan MS Access database in vb.net 2005.
Problem:
MS Access DB is opening when Access Run-Time (But no Full version of MS Access) is installed in the system as well. But showing error while scanning through our Tool.
Solution:
Need only Full version of MS Access.
Suggestion:
To Identify, whether the required application (like here we need MS Access Full version) is installed or not at the time of installing our Tool(Through MSI).
Is it possible to identify MS Access Full version with Run-Time while installing the Tool?
As per my knowledge it is possible to identify the application along with its version while installing.
Could anyone suggest me is it possible or not, if yes then please provide me some useful reference or links.
Thank you.
Since you are asking for an answer that tests during your install process, the simplest answer is to query the registry. Prior to Access 2007 there was a specific key for Access Run Time, but it seems that with 2007 you need to check the Installed Packages path of the Office registry hierarchy.
Here's the key for Access 2007 Runtime:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Common
\InstalledPackages\90120000-001C-0409-0000-0000000FF1CE
And here's the key for Access 2007:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Common\
InstalledPackages\90120000-0015-0409-0000-0000000FF1CE
If you later want to re-verify that the setup remains as you want/need it, then try this:
IF SysCmd(acSysCmdRuntime) = true THEN
...
END IF
Related
Am using MS Access 2016 to develop an application managing images. But some of my users are still using MS Access 2007 on their computers. And the receive the error "unrecognized database format".
So I would like to know if there is any solution for this. Like making my application compatible for previous versions.
I did some researches for days but not satisfied yet.
Need any help, solution or advice please. Thanks
Develop using the lowest version that your application will address, here 2007.
A newer version - 2010 and onwards - will run an older with no problems. However, 2007 is 32-bit only, thus - if you use API calls and some users run Access 64-bit - you must take care of that.
I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.
I am not very familiar with Access database till now i was only programming to SQL Server but now it's time to do so. I am building WinForms application which will be using Access database and i have some question related to that point if you don't mind. My application will be used by multiple users and there will be one access databsae. My questions as below:
Is there any problem with accessing access database in same time by many users or only one user can be connected?
If i develop my program to use access 2016 and some of my users will have diffrent windows version and also diffrent access version
will it works?
Should i know something else? :)
If your client want to have a file based database and this is a project constraint , MS Access is the best choice. If you want a more detailed advice, please let me know how many users will perform Read/Write or Read transactions, the size of the database and if the application will run in client-server mode in a LAN/WAN, Cloud or Remote Desktop environment.
Back to your questions:
Depending on these conditions you may range from 10 to 20/25 users. Remember that you can always try with MS Access and later upgrade to a MS SQL database in a couple of hours.
If your front-end application can link to a 2016 Access database, it will do that without installing MS Access to the clients that will run your App, i.e. the vb.net compiled App will install all needed drivers. If you develop your App within MS Access 2016 (Access Form and reports, some VBA) you can run it with the free runtime version of MS Access, but this only when no older version of Access is installed on the running workstation.
Please check with your client the real reasons for a file-based database...
To answer the questions as asked:
You might run into an issue with this, as access was really designed as a personal use database. Having anything more than a small handful of users hitting against it at once will in fact cause problems, as it's not really well designed for that purpose...
This should in theory be fine, as the application itself is interfacing with the database, not the end user...
It seems like you're taking a step backwards using access for this, and SQL might very well be better suited for this purpose. This isn't me trying to just bash access either, this comes from personal experience. Going with this sort of design is likely to cause you more headaches than good.
I have an accdb database that is used by multiple individuals and stored on a network share. When opened in Acccess 2007 the following message appears:
Cannot open database "\\databasepath\filename.accdb". It may not be a database that your application recognizes or the file may be corrupt
Access 2010 opens the database with no problems.
What is the most common cause of this issue? I searched for database repair tools and can't find any Microsoft tools for accdb files (JetCompact didn't do it). I ran a compact and repair via Access 2010, did a save as locally and then copied it over to the share - no effect.
Other than magically upgrading all my users to Access 2010 (which won't happen) I'm in the dark here.
You may have some features you're using in 2010 that aren't supported in 2007.
Look here for more info.
Most likely someone opened it in 2010, edited your report and saved the change. This will break 2007 every time. 2010 is NOT backwards compatible with 2007
I would make a back-up, make another back-up and then first try importing all but the tables that contain attachments into a new database.
you can also check this: https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted
Problem: Could not find installable ISAM
I am executing a query from MS Access in order to pull information from MS SQL Server 2005.
When I attempt to open a linked ODBC connection to the table directly it opens with no issues. However, when I attempt to create a DSN-less connection, I receive an ISAM error.
I have the following error when I attempt to execute my SELECT query:
"Could not find installable ISAM."
The code I'm using is as follows:
SELECT * FROM [Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].[My_View_Name]
The help from MS Access provides the following information:
Could not find installable ISAM. (Error 3170)
The DLL for an installable ISAM file could not be found.
This file is required for linking external tables (other than ODBC or Microsoft
Jet database tables). The locations for all ISAM drivers are
maintained in the Microsoft® Windows® Registry. These entries are
created automatically when you install your application. If you change
the location of these drivers, you need to correct your application
Setup program to reflect this change and make the correct entries in
the Registry.
Possible causes:
+ An entry in the Registry is not valid. For example, this error occurs if you are using a Paradox external database, and the Paradox
entry points to a nonexistent directory or driver. Exit the
application, correct the Windows Registry, and try the operation
again.
+ One of the entries in the Registry points to a network drive and that network is not connected. Make sure the network is available, and
then try the operation again.
I have also found KB articles from Microsoft explaining when and how this should be handled. However they are unclear to me if they are actually rooted from another type of issue.
For example:
283881 and 209805 Tell me the purpose of ISAM is to tell how to format data other then, MS Access' native formatting. (But I don't want to format it in another way and the other formats do not list what I think to be the appropriate format-er)
and, 90111 Tells us the driver in the .ini file may be pointing to the wrong place in MS Access 2.0 which no longer exists in version 97+.
The odd thing is I have a DNS-less setup for another table which works fine. The only difference I see here is the default naming of the database object is not standard, so possibly I am not referring to the schema correctly in my syntax.
What am I doing wrong here? Is it truly a syntax error?*
Are there any "View" permission considerations which need to be made on the server end?
Try adding ODBC; at the start of the connection string and remove the brackets around the view name:
SELECT * FROM [ODBC;Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].My_View_Name