My client wants a pivot table, showing the performance of each month (column headers) per department (row headers). It has to be be possible to insert a 'as-of date' as a parameter, so the user (PHP) can pass that date and the pivot only shows months after that date. My first thought was to write a function. But the pivot has to show a "Totals" column (and a "Totals" row, and a grand total as well). So I wrote a stored procedure, which dynamically puts the pivot together.
The proc works fine, but takes too long to process (which is unsurprising given it's dynamic nature). So I figured I should base an mview on it, or as Microsoft calls it, an indexed view. My approach is to first create a view based on the proc, and then figure out how to materialize it.
It seems that for the first step I need to call the proc inside my view using openquery. That only works if data access is enabled though. So I ran:
SELECT
name,
is_data_access_enabled
FROM sys.servers;
and it turns out is_data_access_enabled = FALSE on our local server (A), but it is TRUE on the another server we use (B). Oddly I can use openquery on B referring to A, something I don't understand but which is probably irrelevant to my question.
I know it's folly (or at least bad practice) to use openquery on server A referring to that same server A, so that's how I got to the point where I ask the community (you people). Would you know a better approach for achieving what I'm trying to do? I use SQL Server 2014.
Related
I have a relatively complex SQL query (complex to run in Access) and want to run it in MS Access. It works with the pass-through query well but going forward I will face an issue that is related to a filter I apply in the query. I select the current report date within the where function. Below is a part of my query I try to handle ;
select LS.PID_FACILITY, LS.ASOF_DTE, LS.DATA_CYCLE_FLG, LS.CUST_ACC, LS.CUST_SMUN, LS.CUST_NME, LS.CUST_CTY,
WHERE LS.ASOF_DTE='19-SEP-22'
I do not want to change asof_dte filter manually everyday. If this was a normal access query I could join another table that includes only the current report date. But I cannot do it in a pass-through query. What is the alternative way to do it? I read something about creating variables or strings, but I could not relate them to my problem, since I am a beginner at creating such solutions.
Thank you all.
Well, two VERY intresting things here.
First, YES a great idea to include the date in the PT query. But, you don't want to change that date each time.
Soluton:
Add a paramter to the query, and then from Access code add that paramter. It is VERY easy to do this (one line of code!!! - don't adopt the zillion examples out there that has a boatload of ADO code - NOT required!.
However, BEFORE we start dealing with above?
A MUCH better and simple, less work way to approach this?
in place of stored procedure?
if possbile, create a view. and use that for the report.
Why?
Because you then get TWO VERY valuable bonus.
First, you can freely use the reports "where" clause, and it respects the where clause and STILL runs server side!!!
In other words, create a view for that existing query, but WITHOUT the date set in that view.
You then link to the view from access client side.
Now, to open (filter) the report, you can do this:
docmd.OpenReport "MyReport",acViewPreview,,"LS.ASOF_DTE='19-SEP-22'"
Now, of couse the above "where" clause can be a varible (string).
NOTE SUPER but SUPER careful here:
If you base the reprot on a pass-though query (that then uses the stored procedure), then the filter occures CLIENT SIDE!!!! (all rows will be returned and THEN filtered if you report is based on that stored procedure.
But, if you use a view?
The the filter makes it to the server side!!!!
While both the pass-through query or the "view" can be filtered with the above "open report" and the where clause we have above?
The view will still filter server side - the pass-though query will NOT!!!
Now, the 3rd way, is of course to build the stored procedure to accept a date parmater.
You then could do this:
with Currentdb.QueryDefs("MyPassThoughQueryGoesHere")
.SQL = "EXEC MyStoreProc " + "19-SEP-22"
END WITH
docmd.OpenReport "MyReport",acViewPreview
So, you CAN add and have a PT query and add a paramter as per above.
However, unless that stored procedure has some speical code, you are MUCH better off to create a view server side, base the reprot on that view, and simple pass + use the traditional "where" clause of the open report command. Even if that view has no filter, returns all rows in the table?
With the "where" clause of the open report command, ONLY those rows meeting that critera will be pulled down the network pipe.
So, say a invoice table with 1 million rows.
Create a view, link the view in access.
base report on that view.
Now, do this:
docmd.OpenReport "rptInvoice",,,"InvoiceNum = 134343"
The above will ONLY PULL down 1 row from the server. Even if the view has no filter and would return 1 million rows.
So, using a view is less work then creating the stored procedure.
But, you can modify the stored procedure to accept a paramter, and then as noted use the above example to modify the PT query you have, and THEN open the report.
I think overall, it is less work to use view. Furthermore, if you have a slow running report now?
Replace the query (move it) to sql server side. Get it working. Now link to that view (give it same name as what the client side query was in Access).
Now, EVEN if you had some fancy filter code in VBA, and used openReport with the "where" clause? It will now work, only pull the records down the network pipe, you get stored procedure performance without the hassles. and the date format and "where" clause for open report is access/VBA style - not sql server style SQL.
So, high recommend you try and dump the stored procedure and use a view (and EVEN better is any where clause works - not just one based on pre-defined parameters for the stored procedure - so you not limited to parameters)
. However, no big deal - the above "EXEC dbo.MyStoreProce " & strDate example would also work fine if you have a date parameter you wish to supply to the pass-though query.
I am currently working on a project of replacing our old access database queries, but on one of them I am not able to view the actual SQL View.
Does anyone know a way to force the view or to export it somehow?
Error causing problem:
The SQL statement could not be executed because it contains ambiguous outer joins.
Note that I can view the Design View without issue but when I right click on the tab and select SQL View is when I get the error.
I did attempt what #LeeMac mentioned below but same error occurs:
EDIT:
This question is not like Ambiguous Outer Joins?
The OP on that question can actually see and edit their SQL.
My issues is that I cannot see or edit the SQL as the SQL View wont open.
Try executing the following VBA code from the Immediate Window (accessible using Ctrl+G) in the VBA IDE (open the IDE using Alt+F11):
?CurrentDb.QueryDefs("YourQuery").SQL
Replace YourQuery with the name of your query.
This should print the SQL code which comprises your query - you can then analyse the SQL to determine the cause of the error.
It's odd this error would arise when merely viewing the SQL content of the query definition.
It makes me think that the query is perhaps referencing a crosstab subquery which is actually the cause of the error, but which needs to be evaluated in order for MS Access to determine the columns available when viewing the design of the query in question.
Try this:
hit ctrl-g, and from immediate window type in this:
saveastext acQuery,"Name of query","c:\test\mysql.txt"
Access ordinarily doesn't allow you to save invalid queries, so it's strange you somehow got into this situation in the first place.
If you can copy the query, you can easily get to the SQL by changing the query to a passthrough query, either through the GUI or through VBA:
Dim q As DAO.QueryDef
Set q = CurrentDb.QueryDefs!Query1
q.Connect = "ODBC;"
Debug.Print q.SQL
Passthrough queries are not validated, so you can freely read and write anything you want as SQL in it.
Note that this is irreversible when done through VBA. You can only change it back to a normal query once you made the SQL valid again. If you do it through the GUI, you can just not save it, though.
I had this problem and the issue was that i had a subquery that calculated fields but did not actually have a table in it. for example it would calculate first and last day of last month which is 2 calculated fields, then it was the first query in a series of queries that were built off it and the last one wouldnt resolve sql as original poster indicated also gave the ambiguous join message as well as query needs input table (which was that first subquery). i put a table with 1 record in it but didnt use the record and it worked.... so it just a needs a table in it.
I would like to be able to tag an SQL query somehow, so I can relate the query execution to the web request that triggered the query. I already have a unique request id, that I tag my logs and other monitoring with, so I can easily do a complete trace across the weblogs and new relic for example.
But when I look at a report of long running SQL queries for example, I cannot trace that back to the request that triggered the SQL Query. I would really like to be able to tag the query with my request id somehow.
I can't find anything online. When I search I just find blogs about storing tags and tag clouds in SQL. Not really what I need.
Hope the question makes sense.
This is a very interesting post...
I hope, adding an extra nullable parameter to your stored procedure(s) will ensure that the profiler will catch the unique id passed during a call (in the trace) whether you use that parameter inside the procedure or not (i.e. to do something meaningful...like inserting into an audit table with unique id, procedure name, timestamp etc).
But I think that will make life difficult as you now have to update all your procedures.
If you already have logging turned on (web server) and it captures the same unique id in its request (log file) along with a timestamp then you probably can code a small utility app that reads the log file and find matching entries in the traced table by the timestamp alone.
The only thing that might go wrong is if your web server and database server have differeing times (you need to offset your calculation accordingly).
I don't know if this will help but it is certainly a very interesting project and I am hoping somebody have experienced this thing and came up with a nice solution.
Will be closely watching this post if such a solution exists....
All the best...
If I understand correctly, you want to follow up the query execution in Activity Monitor. But have you considered using a DMV or SQL PROFILER ?
In my opinion, your best bet would be to wrap it in a stored proc. This way you will be able to FILTER your trace only for this object. Here's an example of a simple select and the same select wrapped in stored proc named sproc1 :
As you can see in this image, you can start a SQL PROFILER trace and filter it on the ObjectName. You can then add other column like CPU, StartTime, ...
If you can't use a stored proc, then I would suggest to insert a comment before the exec like this:
/* ID1234 */
select * from table1
Then use SQL PROFILER the same way but you now filter on the TextData using your ID
Here the result :
My project is in Visual Foxpro and I use MS SQL server 2008. When I fire sql queries in batch, some of the queries don't execute. However, no error is thrown. I haven't used BEGIN TRAN and ROLLBACK yet. What should be done ??
that all depends... You don't have any sample of your queries posted to give us an indication of possible failure. However, one thing I've had good response with from VFP to SQL is to build into a string (I prefer using TEXT/ENDTEXT for readabilty), then send that entire value to SQL. If there are any "parameter" based values that are from VFP locally, you can use "?" to indicate it will come from a variable to SQL. Then you can batch all in a single vs multiple individual queries...
vfpField = 28
vfpString = 'Smith'
text to lcSqlCmd noshow
select
YT.blah,
YT.blah2
into
#tempSqlResult
from
yourTable YT
where
YT.SomeKey = ?vfpField
select
ost.Xblah,
t.blah,
t.blah2
from
OtherSQLTable ost
join #tempSqlResult t
on ost.Xblah = t.blahKey;
drop table #tempSqlResult;
endtext
nHandle = sqlconnect( "your connection string" )
nAns = sqlexec( nHandle, lcSqlCmd, "LocalVFPCursorName" )
No I don't have error trapping in here, just to show principle and readability. I know the sample query could have easily been done via a join, but if you are working with some pre-aggregations and want to put them into temp work areas like Localized VFP cursors from a query to be used as your next step, this would work via #tempSqlResult as "#" indicates temporary table on SQL for whatever the current connection handle is.
If you want to return MULTIPLE RESULT SETs from a single SQL call, you can do that too, just add another query that doesn't have an "into #tmpSQLblah" context. Then, all instances of those result cursors will be brought back down to VFP based on the "LocalVFPCursorName" prefix. If you are returning 3 result sets, then VFP will have 3 cursors open called
LocalVFPCursorName
LocalVFPCursorName1
LocalVFPCursorName2
and will be based on the sequence of the queries in the SqlExec() call. But if you can provide more on what you ARE trying to do and their samples, we can offer more specific help too.
We need to have a semi complex report in CRM that displays some accumulated lead values. The only way I see this report working is writing a stored procedure that creates a couple of temporary tables and calculates/accumulates data utilizing cursors. Then is the issue of getting the data from the stored procedure to be accessible from the Reporting Server report. Does anyone know if that's possible? If I could have the option of writing a custom SQL statement to generate report data, that would be just excellent.
Any pointers ?
Edit:
To clarify my use of cursors I can explain exactly what I'm doing with them.
The basis for my report (which should be a chart btw) is a table (table1) that has 3 relevant columns:
Start date
Number of months
Value
I create a temp table (temp1) that contains the following columns:
Year
Month number
Month name
Value
First I loop through the rows in the first table and insert a row in the temptable for each month, incrementing month, while setting the value to the total value divided by months. I.e:
2009-03-01,4,1000 in table1 yields
2009,03,March,250
2009,04,April,250
2009,05,May,250
2009,06,June,250
in the temp1 table.
A new cursor is then used to sum and create a running total from the values in temp1 and feed that into temp2 which is returned to the caller as data to chart.
example temp1 data:
2009,03,March,250
2009,04,April,200
2009,04,April,250
2009,05,May,250
2009,05,May,100
2009,06,June,250
yields temp2 data:
2009,03,March,250,250
2009,04,April,450,700
2009,05,May,350,1050
2009,06,June,250,1300
Last column is the running totals, which starts at zero for each new year.
Have you considered using views. Use a heirarchy of views if it is very complicated. Each view would represent one of your temporary tables.
EDIT Based on comments
I was thinking of SQL views, basically the same SQL as you would have written in your stored procedures.
I haven't done this - just thinking how I would start. I would make sure when the stored procedures populate the temporary tables they use the Filtered views for pulling data. I would then set the access to execute the SP to have the same security roles as the Filtered views (which should be pretty much to allow members of the PrivReportingGroup).
I would think that would cover allowing you to execute the SP in your report. I imagine if you set up the SP before hand, the SSRS designer has some means of showing you what data is available and to select an SP at design time. But I don't know that for sure.
First, since most cursors are unneeded, what exactly are you doing in them. Perhaps there is a set-based solution and then you can use a view.
Another possible line of thought, if you are doing something like running totals in the cursor, is can you create a view as the source without the running total and have the report itself do that kind of calculation?
Additionally, SSRS reports can use stored procs as a data source, read about how in Books online.
I found the solution. Downloaded Report Builder 2.0 from Microsoft. This allows me to write querys and call stored procedures for the report data.
Microsoft SQL Server Report Builder link