Attempting to copy/paste a 159KB TSQL query into Microsoft Access 2010 passthrough query editor (to a Microsoft SQL Server 2008 backend).
This produces pop-up error, "The text is too long to be edited".
What is the maximum length of a query in Microsoft Access 2010?
The help file says that the maximum number of characters in a SQL statement
is approximately 64,000. It doesn't mention any difference between pass
through queries and other queries, so in the absence of any specific
documentation I'm assuming that this also applies to pass through queries.
Looking for this myself and found another limitation that is more likely to be your problem as well as mine:
Maximum number of JOINS in a query: 16
Maximum number of nested queries: 50
Related
I'm trying to compare MS Access SQL queries for local table vs linked table
(it is linked to an Oracle and to a SQL Server database).
I can get query duration when running the SQL command directly on Oracle or SQL Server, but when running the SQL in MS Access, I don't know how to capture the query duration.
Is there a way to get the query duration when running a SQL command inside MS Access?
Thanks. :-)
Yes, it is.
Record in a variable the actual time.
Create a recordset with data source pointing to your query/view/table
Open the recordset (eventually you may check the recordcount)
Record in another variable the actual time
DateDiff between 1. amd 4.
Access does not provide that sort of information, unlike server databases.
You could use a Form Timer and get an idea of the duration, but with linked tables a lot of that depends on the network, server overhead, etc.
I have using Microsoft Query in Excel 2007 for the past few weeks and have had many cases where the query works fine in SQL Server 2005 but gives irrelevant errors in Microsoft Query. For example I have this case Multipart identifier error in Excel 2007 MS Query but not in SQL Server 2008 where when I removed the sub queries in SELECT and joined those tables it worked. It doesn't seem to work in this case too.
Pass parameters to temp variables in MS Query on SQL Server from Excel I guess CTEs don't work in MS Query like CTE in MS Query Excel 2007. It doesn't work in this case too. Alternative to Left Join
Can anyone list all the SQL Limitations in Microsoft Query?
I often found that queries that run on Oracle, AS400 and MS Sql wouldn't run on MS Query, I think the reason is because that MS Query always tries to display the query graphically. If the query is impossible to show graphically MS Query will display a waning message and then display just results (not the table or conditional panes). Simple queries work fine but there is a middle ground between complex and simple that MS Query seems to choke on.
The solution I found was not to simplify my queries, but to actually make them more complex thus forcing MS Query not to attempt a graphical display. I did this by making my queries a sub query and entering into MS Query like so:
SELECT * FROM (
--enter your query here
) a
I have had an odd error I cannot explain. Basically, I am running a query to my SQL database using excel and am having non-existent data pop up when it comes to a very particular order in my database.
Here is a simple query surrounding this order:
select * from OR200100 where OR200100.OR20001='0000793605'
Here is the output in EXCEL
And here is the same output in SQL
what is happening here? How could the same query generate 2 different results?
Run SQL Server Profiler against the database if you can, then compare the output to the sql query that you are running in ssms.
OK, so it's SQL Server then, that's important because different SQL products can have very different idiosyncrasies and controls.
The next things to check are these:
Is OR200100 a Table or a View? If it's a view then post it's code.
Are you using the same Login/account from both Excel and SSMS?
Are you sure that you are connecting to the same Server and Database? SSMS tells you what you are connected to, but client apps like Excel do not and it is very common for this type of problem to be caused by the app connecting to a Dev or QA version of the database. See here for some of the different ways that this can happen:
So I had a very similar problem, my query was grouping by week numbers. What I found was that one of the queries had set datefirst 5 set whilst the other didn't. I guess the key thing here is make sure, if you are using any SET operations in your ssms queries, these are identical to those in the Excel query string.
I love SQL Server Management Studio's 'Find in files' capability -- searching specific file types along multiple pre-defined paths for specified strings. (I have a PERL-driven ASCII editor which does something very similar.) But I am needing a batch process to execute the same sort of argument-rich search for many MANY DIFFERENT strings. I had assumed that once I ran a preliminary search, the query windows would provide (along with the search results) the SQL query syntax executed to produce that search -- which I could then use as a template for creating a complex query or batch search. I see now that this 'Find-in-files' capability in Management Studio isn't a SQL query at all, but a process apparently internal to the software itself. I'm an avid SQL user, but not really a SQL programmer. Does anyone have a simple approach to accomplishing this sort of search in a 'scalable' SQL query?
i have a view that is using linked server to retrieve data from a remote server in SQL Server. On each time viewing the view, the results returned are vary. For example, 1st time execution may return 100 rows of records but on 2nd time of execution, rows returned are 120 rows. Any ideas what is the cause?
I have witnessed odd linked-server results that are a product of non-determinism written into the SQL itself, I.e. a TOP query written without an ORDER BY clause.
This problem, for example, where the chap had multiple non-unique foreign keys coming from a table source on the left hand side of a linked-server INNER JOIN, and wanted 10 rows from a remote sub-query to the right, where the end result was restricted to 10 rows itself, when it should have been greater than 10 rows.
Should definitely give your SQL a quick eye for such curiosities.
The data on the linked server changed between executions?
Is your SQL Server fully patched? SQL Server 2008 and 2005 both have bug fixes out related to incorrect query results from linked servers.
Here is one example:
969997 FIX: You receive an incorrect result when you query data from a linked server that is created by using an index OLE DB provider in SQL Server 2005 or in SQL Server 2008
Is the linked server also a SQL Server? If not, perhaps a buggy driver? I've seen odd results, for example, due to an old Informix ODBC driver. Are you able to run something akin to SQL Profiler on the linked server to see what command it's receiving?
I'm not sure what the answer is, but (assuming that your counts of 100 and 120 are accurate) can you not capture the data from the two runs and compare it? That might give you some clues as to what's going on. For example, is it completely different datat, or is it duplicate rows (in the 120 row batch).