How can I link query from another MS Access database? I know I can easily link tables, But I don't know how to link queries. The query takes data from many tables which I don't want to link.
You can do it this way:
SELECT [RemoteQueryname].* FROM [RemoteQueryname] IN 'C:\RemoteDatabase.mdb'
I have tested with databases locally on my machine and runs flawlessly. The only note I would like to point out is before running the query check to make sure the remote databse is closed or it will crash the one trying to do the query.
The "official" way, by which I assume you mean using the buttons on the ribbon, TMS, would be to use a Make Table Query. Of course, to update the linked data, you would have to run the make table query every time.
Related
Desired result and why:
I have a lot of old Access databases that we are trying to get to SQL Server, and I'm essentially trying to make the Access DB the "middleman" so our old programs can still read/write to them but the information will also be saved in SQL Server. We need the middleman because of how interconnected these tables are through various programs we are rewriting in modern languages. Once we rewrite all of them we will cut the cord and live in SQL Server, but this will take a lot of time.
What I've tried:
We tried creating a linked table to SQL Server and renaming it so it would take the place of the original table. After doing this the table stopped receiving data so we quickly reverted back.
In order to investigate this I created Table B which is just another linked table to SQL Server, and then tried using the After Insert macro on Table A to send any new rows to the linked table but nothing happens. If I manually add a record to Table B it carries over to SQL Server just fine, but I can't get Table A to send data to Table B. I created Table C that is just a local access table and if I manually add a record to Table A it does show up in Table C. No errors at all, it just doesn't do what I need it to do.
I'm lost on how to accomplish this and open to any help or suggestions on how to move forward with this. One thing to note though, is that most of the access databases I have are not using forms at all which is I'm trying to take the macro route instead of any VBA. I need these to trigger without any interaction from the user.
You should use the tool dedicated to this task:
SQL Server Migration Assistant for Access (AccessToSQL)
Ok, there are from comments some new and signficant moving parts here.
For example, data is to be migrated to sql server. As noted, EVEN in access land, all and every table needs and should have a PK for the "basic" data base operations. While it is possible to do some work, and say some importing of data, the instant one wants some forms, VBA code and starts to build a working applcation? Then all tables should have a PK.
And of course if you moved the data to sql server, then it not going to make a lot of sense to have OTHER applcations attempt to modify the linked tables in access, since the data is not in Access anymore!!! Those other sources in theory should thus also hit sql server, and not attempt to use what amounts to a link on a linked table.
However, it does depend. For example, if you use vb.net code and say open a access database, you CAN in fact have that vb.net code open a access table, and in fact it can be a linked table. (however, it would make a WHOLE lot more sense for the vb.net code to open and hit sql server - introduction of a link on a link is going to be problematic.
However, in testing, I have found that say vb.net can open a access table, and even if it is a link, then access will translate though the jet engine (the access data engine), and you can do this.
However, data macros and table triggers on existing access tables? They might work on linked tables, but you of course need to ensure that the linked table does allow edits, and allows inserts. Only AFTER one has verified that you can click on a linked table to sql server - can edit, and then add should one mess around with data macros and triggers on say local tables.
it also depends on what the new software tools and platform is being used here.
But, from a basic database point of view - and general data mangement?
All code, and designs should assume, and be designed around the assumption that each row of data has a PK. This is not always possible, but is a RARE use case.
Practical data management - and use of a database should from both table designs, and from workflow designs, and from a developer point of view assume the concept of a PK row id. Without such assumptions, then you not in the software industry anymore - but in a hack field, and one that will result in great future difficulty when attempting to build work flows and build general information systems.
So, with above in mind: Your table B - it has to work as a valid sql server table.
The sql server table(s). They need a PK, and after linking to sql server, you can open up the linked table in access. Test if edits work, test if adding works, and even perhaps test if delete works. Only AFTER such time, do you now want to start testing any code or other operations from the Access client side.
Introduction of using a linked table from another application? That is a foggy area, but I can confirm for example that say .net oleDB provider will and can open a access database and use + consume even linked tables.
You also don't mention if you using sql logon, or windows auth for the sql server linked tables. But if you using sql logons, then when linking a table, you see this check box - and you want to ensure you selected this when linking the table(s) in question:
Note that you ONLY get this prompt on the first time create of the table link - additional use of the linked table manager (such as re-fresh links) does not offer this prompt. If you don't select the save password option, then you often see a sql logon prompt when you attempt to open a linked table in access.
I am trying to generate a data only script for a view using SSMS Generate Scripts feature. However, even though I select Data Only, it still only generates the view definition and not the data generated by the view. Is there something else I need to do?
I'm using SSMS for SQL Server 2014.
I know this is old, but I will answer it for other people who stumble on it.
Generate Scripts -> Data Only is bugged for views.
The easiest option without searching for other stored procedures or external tools is to copy the view contents into a table. Generate Scripts -> Data Only works fine with tables.
For example,
SELECT *
INTO NEWTABLE
FROM dbo.Component
Then you can do Generate Scripts on the NEWTABLE and select Data Only in Advanced and it will work.
You can then delete the NEWTABLE.
Given that Generate Scripts still doesn't appear to work for view data as of SSMS v17.9.1, an alternative depending on your needs might be to use the SQL Server Import and Export Wizard. You can read data from a view and write it to a table, across different databases and servers without resorting to a linked server.
SSMS is still poor at this, VS has been able to do this for a while
Use menu VIEW->SQL SERVER OBJECT EXPLORER
Create a new server
Navigate down to your table or view , right click -> View Data
use the filter to limit the dataset to what you are interested in
Then use the SCRIPT command (also available on context menu)
This works for views and tables.
Not super easy, but ill give it A-. Way better than other hacks that used to be available (including SSMS.ExportData which is not great)
hope that helps someone. I just had to export some rows and had to re-remember how to do this.
hope it helps someone...
greg
So I need some help, I have a MS Access database. I have a table that I run about 4 queries on. It takes about 5 min to open or save query 4 because it runs against 3, 2, and 1. Even though it is running locally. I was thinking that running it on a SQL server would go faster. The question is, can I do the same thing on a SQL server? Will I need to create stored procedures or is it even possible?
This is a bad question, but I'll try to answer it. Depending on how you build the SQL Server database, the queries will most likely run better on SQL Server. However, you will have to build it properly. In Access, you may even be able to just properly index or construct the tables and it might run fine.
Open a new question with actual SQL code and schema descriptions and maybe someone can help you just in Access.
i'm using vb 2008 and local database sql server compact 3.5 to build a application.
the problem is that i can't insert a new data to the database from the app. i'm wrote the query right at dataset and using table adapter. but when i call the query, it succeed but the data don't exist at database.
for example:
at table adapter, i made AddData() like:
INSERT INTO supplier (kode_supp, name)
VALUES (#p1,#p2)
so at the app, i actually can call them by write: frmSupplier.tableadapter.AddData()
but it's not working, do i miss something to connect the db?
help me..
EDIT:
how can i call a commit or update method then?
and yes, i use datagrid to show db data.
when i run the app, all data in db is showed.
it means that the db and app is connected right?
but why when i add data, it's not working. actually when i run it, it says that adding process is success, no error, and it shows at the datagrid.
but when i look at database. the data that i add is not there.
and in tableadapter, i also make sortData, seachData query, i can use both of them perfectly when i run the app.
so, i really confuse why is the insert query didn't work.
did i miss something to connect the sqlserver compact 3.5 with vb 2008? but some of them works.
You may need to call a commit or update method in order to do this. Not forgetting that when working with data in an app there are often times when you are essentially disconnected from the database and modifications you perform in an app - in memory - may well be some modified view of the "actual" underlying data in the database.
Would be better to show up more codes as it is more clear on the process. First of all, how do you execute the query? Second, how do you pass the value into AddData() function?
look at the following URL may give you some ideas
http://support.microsoft.com/kb/308055
Is there any handy tool that can make updating tables easier? Usually I got an Excel file with the original value in one column and new value in another column. Then I write a formula in Excel to create the 'update' statement. Is there any way to simplify the updating task?
I believe the approach in SQL server 2000 and 2005 would be different, so could we discuss them both? Thanks.
In addition, these updates usually request by "non-programmer" (which means they don't understand SQL, so it may not feasible to let them do query), is there any tool that can let them update the table directly without having DBAs do this task? Also, that tool needs to limit the privilege to only modify certain tables. And better has a way rollback the change.
Create a DTS package that will import a csv file, make the updates and then archives the file. The user can drop the file in a specific folder designated for the task or this can be done by an ops person. Schedule the DTS to run every hour, day, etc.
In case your users would insist that they keep using Excel, you've got several different possibilities of getting the data transferred to SQL Server. My preferred one would be to use DTS/SSIS, as mentioned by buckbova.
However, another method is by using OPENROWSET(), which makes it possible to query your Excel file as if it was a table. I wrote a small article about it here: http://blog.hoegaerden.be/2010/03/29/retrieving-data-from-excel/
Another approach that hasn't been mentioned yet (I'm not a big fan of letting regular users edit data directly in the DB), any possibility of creating a small custom application for them?
There you go, a couple more possible solutions :-)
Valentino.
I think the best approach is to expose a view on your data accessible to users who are allowed to do updates, and set up triggers on the view to perform the actual updates on the underlying data. Restrict change to only the columns they should be changing.
This technique can work on SQL Server 2000 and 2005.
I would add audit triggers on the underlying tables so you can always track changes.
You'll have complete control, and they can connect to it with Access or whatever and perform their maintenance.
You could create some accounts in SQL Server for these users and limit their access to only certain tables and columns along with onlu select / update / insert privileges. Then you could create an access database with linked tables to these.