I've followed the guides shown online for creating linked servers, I've attempted it multiple times and I've gone over all the usual suspects like user permissions but they all seem alright. But no matter what I do, I only get a linked server icon in object explorer, there are no tables under it or anything at all really.
I can run queries such as
Select * FROM Fakt000...art
or
sp_tables _ex N'Fakt000'
both of these works and will return the proper data, but nothing is still seen in the object explorer window.
My desired end result from this would have been that I could have accessed this database in an identical manner to a normal SQL Server database via VS2010.
This forum thread might be helpful; if you haven't already make sure your Access database is set to use logon rather than database password.
Related
I've been running into an issue recently when I attempt any tutorials that involve using a SQL database, entity framework, dapper, etc.
When it comes time to publish a database, or utilize an ORM, I'm given duplicate options for the same localdb under SQL Servers. Furthermore, then I attempt to publish, the database doesn't show up under the localdb that I've chosen.
I'm wondering how I go about removing the other SQL Servers and just having the one available.
If you look at the image below, the Browse option gives me two of the same LocalDbs. Plus I also get a 3rd one under \ProjectModels. I'm wondering what's causing this and how it can be fixed since no matter which one I choose, the sql database I attempt to publish doesn't show up within any of them.
My advice is not to use this method to publish the database. (right click to delete)
Please refer to this official documentation.
File-based databases like SQLite or SQL Server Express are designed to store their data in easily transferable files that can be served with your application/site.
"Copy to Output Directory" Property of the database file to "Copy if newer". Just point the address to it.
If you are using a server-based database like SQL Server, MySQL, etc., you need to make sure that the target machine/environment has the same database server installed, and you need to write a deployment script to append the pre-populated data files to the server. This might be troublesome for you.
You can also refer to these links. 1,2,3
I am having to develop an application very rapidly. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs, triggers etc in the backend.
However, for UI (logon, reporting etc), I am using Access 2010 for the frontend. I am new to both Access used earlier versions of Access waaay back in the day) and SQL Server (familiar with other Db's).
The goal is to have the database reside on a server and let clients connect with an instance of Access 2010 running locally on their machine.
I am looking for a quick tutorial that shows me how to use the SQL server objects from the Access frontend (I believe its called linking) - any link to useful resource would be very helpful, as I can't seem to locate anything useful (I may searching using the wrong keywords).
Assuming you built all the tables and data on SQL server, then in Access it is a simple matter to link Access to that database.
And to save development time, you can continue to use the Access simple approach of using forms bound to those tables. As long as you launch a form with some kind of criteria (say an invoice number), then that bound form will ONLY pull down the one record from SQL server into that form. (so need to write or use store procedures etc. for that form). And any triggers etc. you have built in SQL server will run without you having to do anything from the Access side.
So a plane jane form build in Access that is bound to a table of say 1 million rows in Access does not need any “special” code – just make sure you launch the form with the “where” clause that Access provides and the form will only pull + load the one record.
So 99% of the normal development process you used in Access in the past will continue to work. Using SQL server for the most part does not change much if anything in regards to building forms that edit such data.
However, for reports and some forms that query + search for data etc., or some VBA code that needs to “process” data, you are most free to call store procedures. You simply create a pass-through query in Access. The VBA code to use that T-SQL thus looks like this:
Currentdb.QueryDefs("MyRawt-sqlPassThoughquery").Execute
Or
with CurrentDb.QueryDefs("MyPass")
.SQL = "exec sp_myProc"
.Execute
end with
In the past for most access applications you likely used liked tables – those linked tables can be to a Access file (back end), or Oracle, or SQL server – how the actual application works and functions is really much the same for all cases. (so there not really a lot of “specific” things you need to know from the Access side – if you comfortable with Oracle, or SQL server, then using Access as a front end works just fine, and the typical development approaches used in Access will remain typical.
Here is an article that outlines the linking process:
https://support.office.com/en-us/article/Import-or-link-to-SQL-Server-data-A5A3B4EB-57B9-45A0-B732-77BC6089B84E?ui=en-US&rs=en-US&ad=US&fromAR=1
Keep in mind you will see MANY articles that talk about ADP projects - they have been deprecated since Access 2010, and I don't recommend using ADP projects with Access - so be careful, since many articles that talk about Access + SQL server are built around ADP projects which as noted should not be used anymore.
This office.microsoft.com article should give you a good overview.
With plenty of more technical information searching for "query sql server from ms access".
Don't mess about with linked tables. Use an Access ADP (Access data project), which is natively connected to SQL Server. Sadly this type of access file is being phased out but it is the optimal solution for an MS Access front end with a SQL Server back end
Pros and Cons of Access Data Project (MS Access front end with SQL Server Backend)
Is there some way to create a view in a database that links to non-existent tables?
We've just discovered that a data import routine has been failing for a period of time because of a rather large upgrade that accidentally removed a view.
The view (in the database for our product, hosted on a client server) was linked to a table in one of our customers databases, and created by our client for the purpose.
The accidental removal of this view was due to the quantity of database changes (including the creating and dropping of views), and the fact the SQL comparison tool was going to drop the client-specific view was simply missed.
So it would be really useful to be able to create a copy of this view on our local development databases (with full qualified names to the client tables that we obvious don't have access to outside of the live environment) so this doesn't happen again.
(The customer in question is running SQL Server 2008, however this is a product that is also run on 2005 environment for other customers. So an answer for 2005 would be preferable, but if it's 2008 specific that isn't a problem.)
Update:
To respond to #Damien's comment...
I understand what you're saying, and creating an empty table that is being linked to in the view would make a lot of sense.
Unfortunately the table in question is hosted not only in a different database, but on a different SQL server. That would mean that I would have create a new server instance on all our development machine, in order to host this single empty table. And I would have to do this on quite a number of our clients, resulting in a LOT of practically unused server instances.
I'm really hoping to be able to avoid this, and instead be able to create the view (which obviously will fail in our development environment) but will not be accidentally removed again in the future.
Update 2
I've taken on board what #Damien has said and implemented this using Linked Server... see my answer for more details
As #Mark says in his comment under my question, it doesn't appear to be possible to do this with a view. ("Deferred Name Resolution" exists for stored procedures, but not for views).
The way I've gotten around it is to roughly follow #Damien's suggestion by creating a new instance on my development machine, which is purely going to be used for these "client specific empty tables".
Then I created a Linked Server object to this new instance with an alias of the clients server name (using this answer on SO in order to create the Linked Server object), and in the instance I created the appropriately named database and appropriately named table.
The service for this new instance has been set to Manual start, so it shouldn't be taking up and resources - and I can get it up and running when necessary for any future work.
The result is that I now have the view in question in my development database, and it "compares" exactly with the view in our client database... so it will never (theoretically) be deleted as part of an upgrade again.
I'm writing an inventory/payroll system, and I'm storing all the records on a remote server running SQL Server 2005 on Windows Server 2008 R2. I was wondering how I could start writing forms(very basic) in MS-ACCESS 2010 to upload things to the database. I just want to test it out to make sure that once I implement the entire database, things will work smoothly and without error. I want to figure out how to just make a single form that will be connected to the database, right now the form will just be a simple single text input with a submit button, that will be uploading barcodes(strings not images).
If I need to clarify anything, please just ask.
Thanks in advance for any help
Microsoft has tons of useful "Getting Started" articles.
This one explains how to connect to SQL Server: http://office.microsoft.com/en-us/access-help/import-or-link-access-to-sql-server-data-HA010341762.aspx
This one covers all sorts of forms: http://office.microsoft.com/en-us/access-help/CH010369205.aspx
Go there, you will find a lot that can help you with whatever you are going to do.
Make sure you have the SQL Client driver installed on the workstation where you'll be using MS Access. You can download it here (look for sqlcnli).
The simplest way to get started is to build an ODBC DSN. Access can then link to your SQL Server tables using that DSN. How to Create a DSN
In Access, Go to the "External Data" option and choose ODBC. Locate your DSN and then select which tables you want Access to be linked to.
After your linked tables are showing up in the tables list, click on one of the tables, go to the Create tab (2007, not sure about 2010) and choose Form. This should automatically create a form for you using the table you had selected when you clicked the Form button. There's no need to write code or add buttons to this form. The default form can do all CRUD operations as long as permissions for all CRUD have been granted to the username you used when you created your DSN.
Some developers prefer to use ADO (code only, no linked tables or form wizards) or Pass Through Queries to access SQL Server from Access. I can't really tell you what you should be using because it depends on so many different factors including (but not limited to) size of project, amount of records, skill level, personal preferences, etc.
I've seen lots of questions regarding moving data from Access to SQL Server, but I'd like to go the other route. Here's why:
I've been working on a sizable project with a SQL Server 2008 back-end and Access 2007 front-end. I'd like to be able to do some work on the front-end from home over the weekend, but I don't have access (VPN or otherwise) to SQL Server from there. I'd like to change my linked tables from SQL Server to another Access database file where I imported a snapshot of the SQL Server data. Then, come Monday morning, switch links back to SQL Server.
My problem is when I go to the Linked Table Manager and attempt to change the link, all I get is the ODBC Select Data Source dialog. If I try to link to an Access database, it tells me ODBC can't be used to link, import or export to another Access file.
One thought has occurred to me but I haven't tried yet; maybe someone could tell me if it's a good or bad idea: would I be able to delete the links, re-create them to the other Access file, and not lose any functionality in my queries/forms/reports?
My proposal would be to have SQLExpress (free) installed on your computer. You can then have all the data available on the machine. Create a publication on your main server, and have your local machine suscribe to this replication (if you don't need to save/synchronize the data changes done on your machine, you can stick to a basic 'snapshot' replication.)
You then just have to change your connection string from your network MSSQLSERVER to your localhost SQLEXPRESS server instance to have your app work.
If, for any reasons, you have to make changes to the database model while being off-line, you will then have to unsubscribe from the main server before making the changes on the local server. When you're back to the office, make sure that the same changes are done on the main server. My advice is to write your changes in T-SQL, save them in a file, and launch the file against the main server once you're back to work.
My opinion: don't work too much on weekends, or make sure your client is being billed for that.
For linking tables, you need to delete them and entirely and recreate them. Using the linked table manager to refresh ODBC links doesn't even work reliably when you're still using ODBC, as there is data cached in the table link definitions that doesn't get refreshed (e.g., if you change the number of columns in a SQL Server view, refreshing the table link with Linked Table Manager will update the number of columns, but you won't necessarily get an updateable view (assuming the original was updateable)).
But it's not clear whether or not you'll lose functionality or not. That all depends on how much of your application's logic is server-side, in SQL Server views and stored procedures. None of those will work if you link to a Jet back end.