I created an Access front end for a SQL DB on my PC for use throughout my company. I am using a file ODBC connection and putting both the ODBC file and the Access file on a shared network drive.
When I load the access file, for some reason it seems to default to using my windows login credentials and pulls in the data perfectly. When a user attempts to open the file, they receive an error message saying "ODBC --call failed.". I can open the Linked Table Manager for them and check 'ask for new location' then specify the ODBC file and it all works fine...however it doesn't seem to save anything. I get the error each time someone other then myself opens this file.
Any idea what could be wrong? I am not an Access guy by trade, it just seems to be the tool we need for the moment.
--EDIT: For Clarification I am using a file ODBC connection
--Edit 2--
Riddle me this. So I have been troubleshooting this issue and I came across something interesting. I was logged in as one of my users and did the following:
Create a new access file that references a file ODBC connection on the desktop.
Create 3-4 linked tables in the access file, using the ODBC file on the desktop.
Save and close the access file.
Re-Open said file.... and I get an ODBC connection error! Right after everything was fine in a fresh file!
Anyone ever experience this?
i assume you didn't install the ODBC correctly on each users PC.
you should create the ODBC-definition. You can create the relevant statements directly in the registry, see this branch
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
if you give the same name as on your developer machine, then it works. that's how i do it with my client applications that i develop on my machine and then install it at client site
After beating my head against the wall having this same issue, I finally discovered I had a checkbox on the Access form that defaulted to NULL. Since I put the backend into SQL, the checkbox fields cannot be NULL but the 'ODBC Call Failed' message did not help. I finally tried to add a record directly on the table via Access and it gave more information. I set all the checkboxes to default to zero and it resolved the problem!
Well, I was able to narrow the issue a bit. Access for some reason keeps trying to use Windows Credentials instead of the username in my ODBC file. I can't find a way around it, but I was able to resolve the issue by creating logins on my SQL Server for the windows users that need access.
I am not incredibly happy about needing to manage more logins, but that's what i did to resolve this issue.
I don't mean to resurrect the dead, but I had this same error stem from a different issue.
I was using an ODBC connection. When running the file using the 'Design' run button it worked fine. When I tried using the Navigation Pane and double clicking on it, the error would happen.
The structure of my query was the problem; I was porting a SQL server query over and the single quote ' parameter passing was not well received in Access. Changing these over to double quotes " made it work.
Related
I have a strange issue when trying login to my WPF application I published. I am using Microsoft SQL Server 2016, I am also a Server admin. I have a Database called Project Tracking in the server. When trying to log in I am able to login just fine. When another user tries to login they get this error: The underlying provider could not be opened.
Now, if I add them as system admins to the SQL server they are able to login just fine no errors. Although this is not what I want to do for obvious security reasons. How do I go about actually adding them for read/write access to the database?
The connection string in the application is: "metadata=res:///Model.ProjectTracking.csdl|res:///Model.ProjectTracking.ssdl|res://*/Model.ProjectTracking.msl;provider=System.Data.SqlClient;provider connection string="data source=EPLANDB\PROD4W;initial catalog=ProjectTrackingDB;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient"
This is my first go around using SSMS and SQL Servers, so not sure what exactly the problem is or how to word it correctly, I hope I gave enough information if someone could point me the right direction.
Here is a picture of my setup on SSMS.
I figured it out. I found this article over the subject and it worked for me.
I had to go into Security for the Server right click Logins and hit New -> Login.
Your are then brought to this screen. Click Search...
Not sure if this part matters. But I clicked Object Types and checked the Groups.
Add the username you want to include. Make sure to include the domain name.
Click User Mapping.
Check Your Database.
Make sure to check data reader and data writer and any other roles you would like to include.
Here is where I found the solution.
Answer to Problem
I work with Access daily, and this situation is unlike anything I've ever seen Access do:
I created a database tool in Access for a report I run at work. The other day I was using it, and Access abruptly closed itself down. I went to reopen the tool, and I got an error saying "Microsoft Access has stopped working. A problem has caused the program to stop working correctly. Windows will close the program and notify you when a solution is available."
A few minutes later it prompts me to create a backup, which also does the same thing when I try to open it...
...unless...
I open Access itself and search for the original tool. Then it opens just fine.
I have tried repairing this database, and nothing works. It simply won't let me open this tool unless I go through Access first.
Does anyone have any ideas on this? What gives???
(Windows 7 Enterprise Edition, MS Access 2007)
A few things I would try
1) Create an entirely new DB, and import all of the objects from the problematic database. Any corrupt objects will show as an error during that process. You may get lucky and the new DB can simply be the new production DB.
2) Hold down the Shift key as Access is loading to bypass any startup code.
The problem is likely in the VBA link, which the new DB shell will fix.
I've created a new database using Microsoft SQL Server Management Studio, and now I want to interact with it through LabVIEW. I already have several VIs to interact with a previous database, using the database connectivity tool kit. This database was created by someone who has since left the project and I can't find it in anything but LabVIEW.
I'm quite experienced with LabVIEW, but completely new to and bewildered by databases.
Thank you in advance.
The first Connectivity Toolkit VI called should be Open Connection.
The existing code (VI) will either use a file or a string as an input.
If the input is a string, then you will need to create a new connection string compatible with your server. You can find common SQL Server strings at https://www.connectionstrings.com/sql-server-2008/
If the input is a file name, you can copy the .UDL file that is referenced and then modify the copied file by opening it (double click) and then select the OLE DB Provider for SQL Server and then set the connection options to point to your server, database etc. and then test the connection.
Basically the workflow you have to go through is the following:
Open connection
Execute your query
Fetch data (if needed)
Close connection
If you search for "Database" in the NI Example Finder shipped with Labview you will find a few good starting points.
In particular give a look to Database Connection.vi and Database Fetching.vi.
If you plan to use transactions try also Database Transaction.vi.
I found that the solution to my problem was to create a .udl file and use that as the file path for opening the database connection.
Here's the address that taught me how to do this:
http://msdn.microsoft.com/en-us/library/e38h511e(v=vs.71).aspx
Thank you to everyone who submitted answers, they certainly helped point me in the right direction.
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
Lately there has been a problem running some of our reports in access. Last week(the beginning of the week) we tried to run a reports lets call it A and it kept giving us the log in prompt. Even when the correct user-name and password were entered the log in box would just keep reappearing until cancel was pressed.
I clicked the debug and checked the query. I then logged into the database it is pulling the data from with the same user-name and password and received no trouble. Around Wednesday A was working again, even though nothing was changed. This week A is working but another report B is doing the same thing..
Anyone have any idea what this could be? I'm thinking maybe someone else has the report open? Any help is appreciated.
EDIT: I have narrowed down the error to one linked table that is causing the login prompt. It seems it has the DSN setup but no database specified. So i just need to relink the table..Is there anyway to do this at the GUI level? Also should I leave this question up for future users or just delete it?
Was the login prompt from Access or from Windows? If from Windows, then I'd say that there was some sort of file permission or network access issue at hand. If from Access, then I would say that something in the SYSTEM.MDW that you are using is corrupt or has been reconfigured.
If the login prompt is from ODBC it probably means that the credentials that are being used to access the backend database (per your comments you mentioned it was SQL Server) are either invalid or disabled. (Or it could be as simple as the backend database is/was temporarily unavailable).
If you are using linked tables in Access to a SQL Server it means that an ODBC connection was created and you might try verifying that the ODBC connection is working ( Control Panel, Administrative Tools, Data Sources(ODBC) ). In that dialog there is a place to test the connection.