I'm using the dropdown menus to make macros in Microsoft Access, but I'm confused as to how to save a query into a table, overwriting it. The actions are as follows:
CopyObject([Example1],Table,[Example2]) #for the purpose of the query
OpenQuery([Query1])
But from there I don't know how to get the query saved into a table. SaveObject isn't what I'm looking for, I want it into a table, not saved as a quer Couldn't find any questions on here answering the problem, so I thought I'd ask. Basically, I want to copy-paste a query into a table, as I can do in regular Access, but due to the strict definitions of Access macros I don't think it'll work. I am familiar with SQL, but I'd like to not have to write SQL code as I am doing this multiple times with different names for each table.
Related
I will briefly explain what I have and need here, and later if I can, I will edit this post and add a reproducible example.
My project:
Query data from Oracle databases into one worksheet in Excel, then use a LOOKUP procedure to copy data into an editable table in a second worksheet. The second worksheet needs to be in a table format for filtering, and have a drop down option to filter the data by date ranges. The data needs to be refreshed 1-2 times a week only by 1-2 approved staff members.
Concerns:
Per suggestion I installed Power Query for Excel 2010, which required dependencies before it could work. The convenience factor is great and it makes it so that SQL queries can be edited without messing around in VBA code. However, the dependencies setup (Oracle client for data connections) limits casually deploying this as a solution.
The data connections and queries and the data lookup could all be done in VBA and assigned macros.
Questions:
Should I use Power Query to query the data and then a VBA for the second sheet LOOKUP and date range filtering -- or should this all be written in VBA Excel Macros?
Which is more future proof friendly? Are there any advantages for using Power Query that would make this task more edit friendly for non-coders?
Thanks!
This probably can be solved with PowerQuery only, without VBA. I wouldn't recommend you storing queries in Excel table, the best is to move it on a server. A view or a function would be suitable. Querying the database, editing this view/function will work for only for only approved users.
This is more secure and will require only 1 Excel workbook. In PowerQuery, you can refer old copy of the table at the moment you refresh it, therefore you can keep entered data and get new.
Your project seem to me as an ad-hoc solution.
We work with a lot of data at my job, and I want to try and find a way to limit the amount of copying from SSMS to an Excel sheet that goes to the client.
What I want to be able to do, using SSIS if possible or any other possible way (Maybe power query?), is to copy the data pulled via a SQL query to an Excel workbook sheet.
For example, I want to do a count on the amount of members by state, I'd have the query run and the results copied to the sheet called "State" in the Excel work book.
Example code:
SELECT C.State, COUNT(*) as Count
FROM [dbo].Input I
Join Cassresults C on C.ID = I.ID
group by C.State
order by Count desc
The Excel workbook will never change for the client. The only thing that may change are the queries, but those are easily updated.
Is there a way to actually do this or am I nuts for thinking so? I hope I explained it well enough.
SSAS, SSIS, PowerQuery, PowerBI, Excel PowerPivot, SSRS, and Excel Data Querys all are geared for this type of use. I would definitely NOT recommend VBA as your users will constantly get a security warning and it is more complex than needed.
For Excel probably a good starting location go to the data tab and click "From Other Sources" and check out the different source types. From Micrsoft Query gives you the ability to write a query or copy from SSMS.
The only thing is will Data Sources Change? If so every workbook you create and distribute will the become obsolete and need to be changed. SSRS is a good choice to allow users to grab the report (and export to Excel) that they need.
When doing SSAS it is great as well but start with PowerPivot in Excel, again data connections move Sharepoint data connection library is a way to combat that.
This is like a BI and reporting design question and you will get a plethora of answers.
to export data from an Access 2010 Database I would like to use an Excel template as seen below.
In the first row I can define columns that are in the database. In the second line I can define exactly 1 filter which will be used in the "where" statement.
When pressing a button in Access, a query that is based on the defined columns and filters should be executed and the result will be exported to the Excel.
I am honest, I am not that skilled in VBA. What would be the best point to start from.
Your question is way too broad and as such it should not even be here, but let me give you some points to look at.
First you'll need to get your data from the Excel file. If you are not skilled with VBA, then the easiest way would be opening it through VBA using an Excel.Application object and Workbooks.Open method, and get your values from your Range.
Create an SQL Select statement from your values.
Do not use just a SELECT query, make it a SELECT INTO query (a "make table query" as Access likes to call it). That way your results will be inserted into a (new) table, making it easier to output.
Export your new table to Excel. There are several ways to do this, search for DoCmd.OutputTo or DoCmd.TransferSpreadsheet.
I apologize if this is an easy one, but I can't find this on the web anywhere!
I have a list of tables and queries, and a full list of fields from each table and query.
I want to choose my fields in an Access form, and then, on another form, choose a query/table in one column (along with a field) and join it to a table/query in another column (along with the field.) My form for the joins would look like this:
Object1 Field1 Object2 Field2
and so on. I would want to be able to choose my fields through combo boxes, THEN make the SQL string dynamically. I can't use a where clause -- it has to be a join.
The problem is, the structure will change every time. Access gets funny about putting in parentheses. Also, if an object is chosen more than once, Access will want to join it (assuming I do it right) in a different manner than T-SQL.
Is there a way to write a query in T-SQL, and quickly convert to Access? Does anyone know the FROM clause algorithm Access uses to construct the FROM clause? I am stuck here, and I cannot find a solution to save my soul! Thank you in advance, David
Like a lot of developers who are comfortable with SQL syntax I get frustrated when working with Access's query editor. I'm talking about the raw SQL Syntax view, obviously.
One of its many annoying properties is that upon saving it will discard my layout / formatting. When reopening the query all I see is a bunch of unformatted SQL.
However, if my syntax is long and/or complex enough I've noticed that Access will retain my formatting and layout and, oh joy, the query remains clear and readable. I'm looking at an example right now with a page of SQL containing couple of UNIONs all nicely laid out from a few days ago.
At what point does Access flip over to allowing the user to retain his own formatting? Is it length? Complexity? And is there maybe even a trivial structural edit (if trivial structural isn't an oxymoron) I can make to all my queries which will force Access to leave my layout in place?
There are certain things that Access' query editor is not able to display in design mode.
Queries with UNION are the only thing that come to my mind right now, but there are probably more.
In my experience, Access always changes the layout as long as it's able to display the query in design mode.
As soon as you put something in the query that Access can not display in design mode (like UNION), Access leaves your layout and formatting as it is.
I couldn't figure out why Access kept changing my format in a union query (but not for every query or table included).
I simply created another SELECT query based upon the Union query and corrected everything in design view. It's a lot easier.
When I created the SELET query based upon the UNION query, I included tables or queries that I used as lookup tables and had formatted a field to select the second column from a record in a lookup field that the ubion query had anoyingly converted back to the first field in the selected record (usually the ID No of the record).
For example, I might lookup the account name in a record in the cash disbursements table that should display "Office Supplies Exp" but the Union Query converts at least one of the queries or tables I have combined in the union query to the Account Number, the first record in the lookup table, which was originally hidden in the lookup field.
Just to add to Christian's answer, I've done some more testing and find that UNION and DDL queries are left alone by Access.
If we add Pass through queries to that list, then that would match the queries deemed SQL Specific on the menu:
So, those would seem to be the three special cases.
Before saving just type the word union before the ;.
After opening Access next time, remove the word union and start working. When you want to save, first type union again.