I connect from ms access (frontend) to MS SQL server (database) using ODBC and file datasource. I've created MS Access pass-trough query collecting data from SQL Server (directly calls MS SQL Server function returning table).
When I run this query in MS SQL Management console, it runs about 1s. When I run it from MS Access, using ODBC connection string, the same query runs about 5 minutes (!!). But when I clear connection string from query properties, it runs between 1 and 2 seconds (so acceptable).
Other queries and linked tables using the same connection string works correctly (so the string is rather OK)
Why the hell this one makes problem? Any idea hat to check?
I know this is an old post but... I've been googling to no avail so I wanted to put this out there...
I have a drill down SP that returns.... 200 rows max
The MS Access app uses ALL pass through queries to Azure. All work great except for this one. In SSMS it comes back almost instantly. ODBC string is the same on ALL Queries so the connection is fine.
After setting the max rows property to 1000, the form came back almost instantly. Cleared the property and it went back to slow...
This property definitely made the difference for me. Setting it to a number that is well beyond the upper limit really got this working as it should be.
hth,
..bob
I use windows authentication (trust) only.
"clear" means to remove all except "ODBC;" phrase. When I leave this notice in query properties, the Access asks for DSN, I select one, and then I got the results after 2 sek.
But When I put full connection string
ODBC;Description=My Database;DRIVER=SQL Server;SERVER=MYSERVER;APP=2007 Microsoft Office system;DATABASE=MYDB_Prod;LANGUAGE=polski;Trusted_Connection=Yes
The query I call is:
SELECT * FROM dbo.fn_MyFunction()
Function fn_MyFunction() is table valued one, returns two rows and about 50 columns ( suspected large number of column might be the issue, because other queries have less one), and it is used in access report (that's why I use pass through query - the same happens when I test with MS SQL server view linked to MS Access tablle via odbc)
The same connection string works well with other queries
It seems I found solution (or workaround rather?) I've made the tests using VPN over internet link. When I move to office - it works well and return almost immediatelly with the string I wrote above.
It is strange for me that link type have such impact: other queries works well on both (LAN an VPN over internet), but this one - only on LAN ( works over internet too but with unacceptable performance). I could understand if all works slow.. by why this one? Any idea?
Related
I am using DBeaver to connect to my MS SQL database hosted in local. I try to export my tables as CSV files. In the case where the query is rather big (40k rows which takes a couple of minutes) the export gets stopped with the message
"SQL Error: The connection is closed".
I kept the default parameters for dbeaver database connection, and my SQL server timeout is the default one (10 minutes, which is more than it takes to trigger the error)
Any idea where it might come from?
You know, the value of binary is extremely large and weight. So that takes much time to transfer via the network. That's the reason why you're getting error. In my opinion,
You should split your query into multiple time to fetch data (How about 1k records in each time).
Just get the exactly items that you need (where condition or the columns that you need instead of all)
Every database driver allows to configure the connectTimeout, a parameter that declares for how long the client (dbeaver) will wait before deciding something went wrong.
You can change this parameter right-clicking on the name of the server, choosing Edit Connection, then clicking on the Driver properties tab and searching for the connectTimeoutparameter (or something equivalent). Increase the value you found there.
I had this problem with PostgreSQL 13, found a connectTimeout = 20ms and increased it to 200ms to overcome the issue.
An old MySQL driver showed a connectTimeout = 20000, most probably in nanoseconds.
We recently upgraded our SQL server to 2016 and I turned on QueryStore to do the analysis that it provides. I'm encountering a problem where, even if the time period of the report is Last hour, it will generate a message that says "Couldn't connect to database" even when running it on the database server itself. Sometimes if I keep refreshing the report it will eventually display some data, but it's intermittent at best. I'm running SSMS 17.5 on a sql server 2016 server.
We are having a somewhat similar issue with another program that connects to the database where it will sometimes not be able to connect, but every time I run my queries in SSMS, run reports in SSRS, or even use activity monitor, I never see any connection drops, so I'm not sure if it is related.
Thank you in advance for any help!
I find it works fine with the statistic set to Avg, StdDev, or Total. Max and Min give the error.
I found this happens when the query store runs out of space and gets into cleanup mode.
In database properties in SSMS try playing around with Query Store settings: for how many days it stores the query stats and does it get into "size cleanup" mode. More info on how to keep it adjusted: https://learn.microsoft.com/en-us/sql/relational-databases/performance/best-practice-with-the-query-store?view=sql-server-ver15#Configure
I've done this numerous times in the past when connecting Access queries to Excel, but now when I try and do it with a SQL Server query, I get an error message of
[Microsoft][ODBC SQL Sever Driver]Invalid parameter number
before I can even assign the parameter a value.
Once I got this error message I started to look around online for some answers, and I came across this article here. I followed these steps, which is essentially what I was doing anyway, and I still get the same error. The article is a few years old, so I'm not sure if things have changed since the release of Excel 2016 (my current version).
Is this something that cannot be done anymore without using VBA?
Just to summarize my steps, this is what I have done:
From Other Sources > From Microsoft Query
Select Database from MS Query Prompt > Click SQL button
Paste SQL > Click Return Data Button
Click Definition in Connection Properties window> Swap criteria code with ? in Command Text
Click OK
It looks as though I may have found the issue. When doing the initial connection through MS Query, you are asked to select the data source. Apparently there are two SQL Server options, one named SQL Server and another named SQL Server Native CLient 11.0. Originally I chose SQL Server, after trying numerous ways to fix this issue, I deleted the data source completely from MS Query, and started over, this time I chose SQL Server Native Client 11.0 and it worked exactly as it should. I'm not entirely sure what the difference between the two are, but it seems to have made the difference.
I had this issue as well and it turns out that because I had included square braces around the procedure I wanted to execute it seemed to think it was a parameter. e.g.
exec dbo.[myproc] #foo=?
just changing to...
exec dbo.myproc #foo=?
worked fine.
I think behind the scenes the params are being put in an array and square brackets in the sql is confusing it. Hope this helps. It may well be that sql native client 11 doesn't handle the params in the same way so you bypass this problem.
I'm fairly new to SQL Server. I have done basic admin, backups etc. I have also spent 2 years doing MySQL for a software company offering software support for their MySQL bespoke program. I'm mainly a tech guy (desktop, Networking) but getting my head round this DB stuff!
I have started with a company that run SQL Server 2005 and need some stuff doing, and I am struggling with the syntax more than anything. The company have 4 SQL Servers running the same db's (program wise) for 4 differing locations.
What I am trying to do is copy the updated cost price list from table 1 to the other tables with * criteria. Basically copy table.parts from server1.parts to server2.parts * currencyconvertion field * markup (%)
That bit seems to be quite easy except I cannot get the db's to link. I enter the server name which contains - and the syntax says wrong eg uk-server1 'can't find 'uk'? Also I am unsure in the 4 part address is correct servername, dbname, schema, table?
Right ok. Previously when tried I was unable to link the two servers. I have now resolved this and the server is now linked. I have been told that maybe there is a need for [] to quote'' server name. I have tried this with no success. The problem seems to be the name of the server having a - uk-efacs. as soon as I type this and remember it is now linked the herror is can't find server efacs an uk is wrong?? It's not ready the full server name? WHY?
Figured this out by trial and error just needs [] by server name ie [uk-efacs].db.table.field. This now is ok just need to work on my syntax as the query shows errors.
Try creating a Linked Server record on the server you're running this from. In Object Explorer (in SSMS) expand Server Objects, right click Linked Servers and select new. Select SQL Server and type the name of your remote server and then try your query again. Bit puzzled as the snippet you provided
update partmaster
set partmaster.fsunit = uk-efacs.efacsdb.partmaster.fsunit * uk-efacs.efacsdb.currency.currate * 1.32
Seems to parse just fine.
We have a classic ASP application that simply works and we have been loathe to modify the code lest we invoke the wrath of some long-dead Greek gods.
We recently had the requirement to add a feature to an application. The feature implementation is really just a database operation requires minimal change to the UI.
I changed the UI and made the minor modification to submit a new data value to the sproc call (sproc1).
In sproc1 that is called directly from ASP, we added a new call to another sproc that happens to be located on another server, sproc2.
Somehow, this does not work via our ASP app, but works in SQL Management Studio.
Here's the technical details:
SQL 2005 on both database servers.
Sql Login is authenticating from the ASP application to SQL 2005 Server 1.
Linked server from Server 1 to Server 2 is working.
When executing sproc1 from SQL Management Studio - works fine. Even when credentialed as the same user our code uses (the application sql login).
sproc2 works when called independently of sproc1 from SQL Management Studio.
VBScript (ASP) captures an error which is emitted in the XML back to the client. Error number is 0, error description is blank. Both from the ADODB.Connection object and from whatever Err.Number/Err.Description yields in VBScript from the ASP side.
So without any errors, nor any reproducibility (i.e. through SQL Mgmt Studio) - does anyone know the issue?
Our current plan is to break down and dig into the code on the ASP side and make a completely separate call to Server 2.sproc2 directly from ASP rather than trying to piggy-back through sproc1.
Have you got set nocount on set in both stored procedures? I had a similar issue once and whilst I can't remember exactly how I solved it at the moment, I know that had something to do with it!
You could be suffering from the double-hop problem
The double-hop issue is when the ASP/X page tries to use resources that are located on a server that is different from the IIS server.
Windows NT Challenge/Response does not support double-hop impersonations (in that once passed to the IIS server, the same credentials cannot be passed to a back-end server for authentication).
You should verify the attempted second connection using SQL Profiler.
Note that with your manual testing you are not authenticating via IIS. It's only when you initiate the sql via the ASP/X page that this problem manifests.
More resources:
http://support.microsoft.com/kb/910449
http://support.microsoft.com/kb/891031
http://support.microsoft.com/kb/810572
I had a similar problem and I solved it by setting nocount on and removing print commands.
My first reaction is that this might not be an issue of calling cross-server, but one of calling a second proc from a first, and that this might be what's acting differently in the two different environments.
My first question is this: what happens if you remove the cross-server aspect from the equation? If you could set up a test system where your first proc calls your second proc, but the second proc is on the same server and/or in the same database, do you still get the same problem?
Along these same lines: In my experience, when the application and SSMS have gotten different results like that, it has often been an issue of the stored procedures' settings. It could be, as Luke says, NOCOUNT. I've had this sort of thing happen from extraneous PRINT statements in the code, although I seem to remember the PRINTed value becoming part of the error description (very counterintuitively).
If anything is returned in the Messages window when you run this in SSMS, find out where it is coming from and make it stop. I would have to look up the technical terms, but my recollection is that different querying environments have different sensitivities to "errors", and that a default connection via SSSM will not throw an error at certain times when an ADO connection from a scripting language will.
One final thought: in case it is an environment thing, try different settings on your ASP page's connection string. E.g., if you have an OLEDB connection, try ODBC. Try the native and non-native SQL Server drivers. Check out what connection string options your provider supports, and try any of them that seem like they might be worth trying.
Example code might help :) Are you trying to return two tables from the stored procedure; I don't think ADO 2.6 can handle multiple tables being returned.
I did consider that (double-hop), but what is the difference between a sproc-in-a-sproc call like I am referring to vs. a typical cross-server join via INNER JOIN? Both would be executed on Server1, using the Linked Server credentials, and authenticating to Server 2.
Can anyone confirm that calling a sproc cross-server is different than doing a join on data tables? And why?
If the Linked Server config is a sql account - is that considered a double-hop (since what you refer to is NTLM double-hops?)
In terms of whether multiple resultsets are coming back - no. Both Server1.Sproc1 and Server2.Sproc2 would be "ExecuteNonQuery()" in the .net world and return nothing (no resultsets and no return values).
Try to check the permissions to the database for the user specified in the connection string.
Use the same user name in the connection string to log in to the database while using sql mgmt studio.
create some temporary table to write the intermediate values and exceptions since it can be a effective way of debugging your application.
Can I just check: You made the addition of sproc2? Prior to that it was working fine for ages.
Could you not change where you call sproc2 from? Rather than calling it from inside sproc1, can you call it from the ASP? That way you control the authentication to SQL in the code, and don't have to rely on setting up any trusts or shared remote authentication on the servers.
How is your linked server set up? You generally have some options as to how it authenticates to the remote server, which include logging in as the currently logged in user or specifying a SQL login to always use. Have you tried setting it to always use a specific account? That should eliminate any possible permissions issues in calling the remote procedure...