I'm running MS Access 365 (v16, 32bit).
I've got a saved query and every now and then Access randomly truncates it to just a "SELECT;" and nothing else.
I found this: Do access queries automatically get truncated?
But I don't have sub-queries so it doesn't seem to apply.
Here's an example of a query that keeps getting truncated:
SELECT customer_data.Customer_Number, customer_data.customer_data.Customer_Legal_Name, customer_data.Customer_Business_Name, Sum(orders.Count) AS totals
FROM customer_data INNER JOIN orders ON Customer_Number = orders.CustomerId
WHERE (((orders.Date_and_Time)>=[Forms]![MainPage]![Start_Date] And (orders.Date_and_Time)<=[Forms]!
[MainPage]![End_Date]))
GROUP BY customer_data.Customer_Number, customer_data.Customer_Legal_Name, customer_data.Customer_Business_Name;
I'm using form data in the query, but I've had it happen with simpler queries.
Anyone ever have this happen or have any idea what's going on? I like using saved queries, but I can't have them just breaking on me like this.
Thanks!
I don't really know but perhaps (if it is not a bug or other kind of problem in your system) adding "PARAMETERS [Forms]![MainPage]![Start_Date] DateTime, [Forms]![MainPage]![End_Date] DateTime;" at the beginning of the SQL text
Related
In order to export data through my web hosting service's SQL interface, I have to first run a SELECT call on the table and then click an "export" button at the bottom of the output. The problem is that I am sometimes trying to export hundreds of thousands of rows, and my browser crashes trying to display them all.
Is there a way to limit the number of rows displayed from a SQL call without limiting the rows actually selected? I know that it's possible to export the data directly through the SQL call, but that's pretty far above my pay grade (I tried doing it but I'm getting an access denied error, and I'd like to avoid having to figure that out if I can). I'm pretty new to SQL, so this might be a dumb question (like, I could imagine the number of rows displayed being entirely a property of the interface, not SQL itself) -- but I figured I'd ask anyway :)
My customer is using MSAccess to read SQL Server Data.
Originally they created a linked table to the SQLServer base table,
then in Access, created a Query that aggregated and filtered.
Select f1,f2,sum(f3),sum(f4)
From linkedtablename
where fx = 'somevalue'
group by f1,f2
For security & performance reasons, I built simple a query in MSSQL to do the filtering & aggregating,
and asked the user to point to that instead, with a passthrough query.
So now they have and ODBC 'passthroughquery' doing a 'select * from MSSQLview'
However, MSAccess seems to be really struggling when we do anything with this passthrough.
e.g. Adding the passthrough to a new MSAccess query window takes forever.
Seems as if Access is doing some heavy reading of the source or source metadata each time we interact with it.
Running a select against the passthrough is also taking an age ... but with the aggregating being done by MSSQL, it should be a lot faster !?
So the question is, why does MSAccess struggle so much ?
Is Access trying to profile the source data even without an explicit 'select' being done ?
Or is it trying to read metadata every time we interact with the Passthrough ?
Ultimately, I am hoping that there is some configuration setting that will force Access to treat this like a 'standard' table !
If you use a PT query, keep in mind that if you use this as a source for a client query, then ZERO additional filtering can be used, or will work.
In other words?
A PT query is one of the fastest (high performance) ways to pull data. BUT ONLY if you do NOT attempt to add additional filtering. A PT query cannot be filtered by client side (well, it can, but ONLY after pulling the PT full query source).
As a result?
Use a linked view. They perform JUST as well as a stored procedure and a PT query, but they can and do respect client side filtering. So, for example you can build a client side query against that linked view with criteria, and ONLY the records matching that query are pulled down the network pipe.
this seems somewhat counter intuitive, but PT queries are fast, but they DO NOT respect additional filters client side (to be specific, you can filter against a pt query, but Access ONLY does so after pulling all records in the PT query). So, one would do VERY well to say avoid using a PT query to fill a combo box, or any thing else client side that will and does attempt to apply additional filtering and criteria.
To be crystal clear:
A PT query is great, but ONLY if you going to have the PT query do the filter in the first place. Additional filtering can be done, but that assumes the original PT query did not pull a lot of data in the first place. So a PT query rows pulled is what you WILL GET client side.
In 99% of cases, you are FAR better off to put that query in a linked view, and thus you are free to filter and add criteria to that view (even client side), and ONLY records meeting that criteria are pulled down the network pipe. this includes even using a client side query on that linked view. And this also includes basing a report on that linked view, and say you have VBA to add/provide a "where" clause to that report. (in this case, once again, Access will ONLY pull records based on that criteria. If you use a PT query for the report and attempt to filter - that filtering ONLY occurs AFTER all PT records been pulled.
So, PT queries cannot effective REDUCE bandwidth requirements to ANY lower then what the PT query returns in the first place. However, linked views DO allow and DO respect additional filters applied - even when done client side. As a result, a PT query is not all that useful unless the PT query has the criteria pre-defined and known ahead of time.
So, I would strong suggest you try/test/use a linked view.
In other words, put that sum and group by in a server side view and link to that.
Edit: and you CAN add the where clause to that view client side against that view.
However, because Fx is not a column, then you have to either add that column to the view, or create a stored procedure, and use it this way:
CREATE PROCEDURE [dbo].[GetMyGroupSum]
#fx nvarchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT f1, f2, SUM(f3), SUM(f4)
FROM dbo.TheTableToQueryOn
WHERE fx = #fx
GROUP BY f1,f2
END
Now, create a PT query in Access. You code will then look like:
dim strFX as string
strFX = "somevalue"
currentdb.querydefs("MyPtQuery").sql = "EXEC GetMyGroupSum '" & strFX & "'"
You are now free to use the above query for a report, code or even launch a form based on that PT query.
In MOST cases you are better to use a view, but because the query does NOT return the column you need to filter on, then a PT query is the solution, but in most cases, it is not.
I spent half day trying to figure out why appears an error messagebox
Could not find field 'TransactionTypeID'
in my
database. If you open Form1, then apply any filter on column TransactionTypeID using header (for instance, uncheck Blanks) and then try to open sorting/filtering for second column, appears error message.
Error disappears if I convert combobox to text box or remove from form select table Tenants1. I use Access 2010 32 bit. In this example I simplified tables as much as possible, database created from scratch, data imported, compact/repair doesn't help.
Do you have any ideas?
I found the problem. The built-in datasheet form filtering works in a wrong way if tables joined this way:
SELECT VouchersMain1.VDate, VouchersMain1.TransactionTypeID
FROM Tenant1 INNER JOIN VouchersMain1 ON Tenant1.TenantID = VouchersMain1.TenantID;
If I reverse tables join direction, built-in filtering works fine:
SELECT VouchersMain1.VDate, VouchersMain1.TransactionTypeID
FROM VouchersMain1 INNER JOIN Tenant1 ON VouchersMain1.TenantID = Tenant1.TenantID;
Looks like this is another Access bug.
Also, thanks #Munsterlander, problem disappears if form's recordsource replaced by saved query instead of SELECT
Try referencing your field as Forms!FORMNAME!CONTROLNAME. I assume, based off what you wrote, you are trying to filter a query based on what is selected in the combobox.
Delete the table Tenants1 from your form RecordSource (this table is not necessary and do not exposes fields in the resulting query).
You would also note that your recordsource is set (by Access) ReadOnly (bad design, no join defined). Try to add a couple of Records in the Tenant1 table, say it David and Nathan.
You will find that now your query will output 6 records (and not 2), because the query (with no joins) list one row for all records of table Tenant1 (3) and one row for each record of table VouchersMain1 (2), giving a total of 2*3=6 rows.
I'm running an UPDATE query from Access 2010 on a linked SharePoint 2013 list, but am getting an Invalid Argument error.
My Access DB is about 200 MB, I have tried compacting and repairing the DB. The query "runs" successfully when I select "View"--the error only appears when I actually click "Run". The query I'm running goes like:
UPDATE
SP_Table INNER JOIN Access_Table on SP_Table.ID1 = Access_Table.ID1
SET
SP_Table.Field1 = Access_Table.Field1,
SP_Table.Field2 = Access_Table.Field2,
--etc...
WHERE
(SP_Table.Field1 <> Access_Table.Field1 AND SP_Table.ID1 = Access_Table.ID1)
OR
(SP_Table.Field2 <> Access_Table.Field2 AND SP_Table.ID1 = Access_Table.ID1)
OR
--etc...
;
This question seems to have the same problem, and the solution even seems plausible, but they're both distinctly lacking in detail. I'm not even sure how to view the PK on my SharePoint list, or how to tell if it's the problem.
Any ideas on how to resolve the error?
I was able to resolve the error, though I'm still not sure what was causing it.
I went through all of the fields in my WHERE clause, and narrowed the issue down to two fields that would cause the query to generate the error if they were included. I compared the fields in both tables, making sure that all of the field settings were identical, but wasn't able to make the query work with them.
Fortunately for me, these fields were not particularly vital, and I can leave them out, but if anyone else has any thoughts, I'd love to have a deeper understanding about what's causing the issue.
EDIT
The error cropped up again in a field that I did care about, so I had to figure out what was causing it. It looks like the "Invalid Argument" error can be caused by a few things, including having the size of either the SharePoint list, SharePoint site, or Access DB being too large. In my case, it appears that I was a victim of corrupt data.
After narrowing down which field was causing the issue, I went through and updated most of the data elements manually on the SharePoint list. Doing that apparently overwrote the corrupt data element that was causing my error, because when I ran the query again, the last few records updated without any issue.
Bottom line, if this happens again, I'm going to check the size of the SP list (no more than 5,000 rows), the size of the SP site (ymmv), the size of the Access DB (no more than 2GB) and then narrow down which field is giving me the error, and try replacing those data elements one at a time until I find the corrupted data element.
I found that in Sharepoint Library -- Version Settings -- Require documents to be checked out set to Yes caused this issue. I set this radio button to No and now I can update SharePoint Library fields from MS Access.
I came across the same problem. Turns out I was returning all rows from one table and only those that matched in the other. There was a missing row in the second table. Change the query to return only rows that match both tables and the problem was sorted.
Is there a way to get the last run date from the cache refresh page for a SSRS report and have that displayed on the report? I'd like the user to know when the data was last refreshed.
You can query the ReportServer database directly to accomplish this:
SELECT MAX(els.TimeEnd) AS LastCacheRefresh
FROM dbo.ExecutionLogStorage AS els
INNER JOIN dbo.Catalog AS cat ON els.ReportID = cat.ItemID
WHERE els.RequestType = 2 --Refresh Cache
AND els.Status = 'rsSuccess'
AND cat.Name = 'MyReport'
Also FYI, Microsoft does not support querying the ReportServer database directly, which means fields/schema could change in later versions of SSRS.
Sorry to contribute to old thread, but wasn't finding a lot of hits on this question, so figured I'd add this:
If you include a calculated field in your source query, it is evaluated when the query is run and records along with the rest of your data. For example:
select
field1
, getdate() as QueryDateTime
from
SQLServerTable
and you can then use that value as min/max/first in your report (by definition is the same on every record).
This has to be done by the server dishing up the data, not as a calculated field in SSRS, because those are evaluated at run time, same as now() expression, or global execution time variable.
One downside of course is that you're recording that data and storing it, then having to retrieve a bunch of redundant data when pulling it, so it's not really efficient from a purist I/O perspective. I suspect the cost of one column of a single date value is not too much to worry about in most cases.