I've used temporary tables before without any trouble, but today, they are not working for me. This returns
. #MyTemp not found
from the last line.
scBld.CommandText = "select top 10 * into #MyTemp from elig_feeds";
scBld.ExecuteNonQuery();
scBld.CommandText = "select count(*) from #MyTemp";
int p = (int) scBld.ExecuteScalar();
If I remove the "#"s, it works fine.
The only thing that has changed recently is version compatibility of the database, but I don't see that would be a factor. The db is 2005 developer edition.
Thx.
I had similar issue today with 2005 Express both using ODBC and OLE DB.
As explained in this article this behavior might be due to using prepared statements, which are wrapped into temporal stored procedures when prepared.
In SQL Server 2005, SQL Server 2000, and SQL Server 7.0, the prepared
statements cannot be used to create temporary objects and cannot
reference system stored procedures that create temporary objects, such
as temporary tables. These procedures must be executed directly.
Supplying statements directly using SQLExecDirect did help to fix the application. Not sure how that should be applied to ADO.NET though.
Check if connection is getting closed automatically. You are executing two different commands, depending on connection settings, it may get reset after you call ExecuteNonQuery().
[Temp tables are destroyed when connection is closed.]
Related
My application consists of a Master Excel workbook WB, and any number of Client Excel Workbooks. All contain reports driven by SELECT QUERYs driven by Excel Data Connections to SQL Server via SQLOLEDB and now MSOLEDBSQL. Those QUERYs in SQL Server include data from the Master WB which is accessed by SQL Server via Microsoft.ACE.OLEDB.12.
The Master WB also creates Stored Procedures in SQL Server using DROP PROCEDURE and CREATE PROCEDURE, whose SQL is configured by data in Excel. Reports in Client WBs are driven by Data Connections that EXEC those SPs. This way I can "hide" file structures of data being picked up from Excel, and also provide a single point of control of the SP SQL. I expect this is a not-unusual structure.
This all worked quite well until sometime last year, 2019. Research now shows that Excel broke this in Version 1907. We're well beyond that now, I'm on version 2004. Now all the SELECTs still work, and EXECs still work as long as they invoke SELECT in an SP. But DROP and CREATE from the Master WB no longer function, and calling an EXEC from Excel to invoke an SP to do the DROP or CREATE also fails.
Others have encountered related issues:
A discussion at Microsoft Tech Community indicates this was broken in Excel Version 1906 and fixed in 1908 - but I haven't found it to fix my configuration. (For reference, found an enumeration of Excel Versions; I'm on Version 2004 of Office 365 ProPlus/Microsoft 365 Apps for Enterprise) (Other config info: Win10 Pro, SQL Server Express 2019, Visual Studio Community 2019, everything x64);
Another Microsoft Tech Community discussion on Disabling warnings on Native SQL QUERYs seems to be helpful, but is not a solution by itself. Also discussed on StackOverflow;
A discussion at Power BI Community indicates that following a Native SQL QUERY with "SELECT 1 FROM someExistingTable" solves the problem. I've found that to be helpful too but also not a solution by itself.
I've found that I can make DROP PROCEDURE work if I have
Disabled Native SQL QUERY Warnings as above;
Followed the DROP statement with a SELECT 1... statement as above;
And the Connection builder in Excel now forces me to connect to a Table in Excel, even if the SQL in the Connection does not return data (e.g. DROP or CREATE). Even if I don't select a Table when defining the Connection, I am required to assign the connection to a table in Excel when exiting the builder. I hate this, but it does make DROPs work. I've been re-using a single Data Connection for DROP and CREATE and to execute some EXECs, updating the SQL commandtext by VBA to the appropriate SQL as needed.
However... Even with all these little workarounds, CREATE PROCEDURE still doesn't work. So I'm looking for help on how to make a Native SQL QUERY to CREATE PROCEDURE work in the current Excel Version.
If there's broader advice and outlook on command-oriented (i.e., not returning data) Native SQL QUERYs in Excel Data Connections, that's also of interest! Thanks.
I am converting an Access 2010 database from using DAO in the native database to using SQL Server 2012 accessed by ADO. Everything has gone flawlessly without too many code changes... except for one thing:
I have some very simple temp tables in which I need to delete all the rows before using. There are no joins or constraints on the table -- just three columns, all of which are part of the primary key.
This is the old DAO code which worked in the MDB:
DoCmd.SetWarnings False
DoCmd.RunSQL ("DELETE * FROM Print_Tickets_TEMP;")
DoCmd.SetWarnings True
This is the new ADO code which produces an error in SQL Server:
CurrentProject.Connection.Execute "DELETE FROM Print_Tickets_TEMP;"
Running this ADO code produces an error:
Could not delete from specified tables (err 80004005).
It's obviously pretty basic stuff which works in SSMS and in an Access pass-through query. So, I thinking there must be some sort of permission, locking or property that I'm not setting. Note that Connection.Execute gets used all over the app with INSERTS and UPDATES.
The only info I found when searching for answers related to issues people had deleting from joined tables. As I noted, this is a simple standalone table. Anyway, I'm at my wits end... if anyone has any ideas on what's missing or can explain why I can't/shouldn't be doing this, that would be greatly helpful!
edit: If it helps, this code is in a VBA module being called from an Access form.
If there is a specific stored procedure causing this problem, try adding these lines to the beginning of the proc.
SET NO_BROWSETABLE OFF
SET NOCOUNT ON
If you are querying system tables, use a forward-only cursor (to be safest, avoid ADODB.Recordset altogether).
If you are using SQL Server 7.0: if you have ANSI_WARNINGS set to OFF, see KB #259775; if you are using the ROUND() function, make sure that the parameters you are sending are not null (see KB #199105)
If you are using SQL Server 2000, and are using SELECT DISTINCT on a table with a LEFT JOIN on a view, upgrade to SQL Server 2000 Service Pack 2 (see KB #308547).
If you are using MTS transactions, try to change your approach by using transactions within SQL Server.
If none of the above solves your issue, see KB #243899.
http://tutorials.aspfaq.com/8000xxxxx-errors/80004005-errors.html
I have this rather awkward problem:
For two weeks now, whenever after I've updated/created stored procedures using my SQL scripts, when these stored procedures are run, they fail with above error.
Other posts dealing with this problem didn't help in my case.
Here's a number of parameters, helping to exclude common solutions which do not apply in my case:
My stored procedure scripts work flawlessly on my laptop (SQL Server 2012, Windows Server 2008 R2).
My stored procedure scripts correctly create stored procedures on any other machine (which is our build machine, with SQL Server 2012 installed; our TEST server, with SQL Server 2005 installed, and our PROD server, with SQL Server 2005 installed). However, the stored procedures won't run on any other machine than mine.
I'm using a database backup of our production SQL Server (SQL Server 2005) on my machine (like any other machine here does).
Even the most basic stored procedure fails (e. g. DELETE myTable WHERE ID = #delID).
On every SQL Server installation I've checked, quoted identifier is set to OFF (!), both on server and on database level. So why do my stored procedures all of a sudden require to have this option set to ON?
I'm using SQLCMD to run my scripts. This gives me an option to dynamically set the server instance's database name in the USE statement.
My scripts only contain a USE statement and right after the ALTER PROCEDURE; or alternatively IF EXISTS (...) DROP PROCEDURE ... GO; CREATE PROCEDURE ...
This all worked for years now, but suddenly, since two weeks ago, stored procedures created with my scripts suddenly fail.
I know that I could manually set QUOTED_IDENTIFIER to ON in my scripts - but I don't want to. There is something wrong here. I want to know what that problem is.
What's happening here?
SQLCMD sets the QUOTED_IDENTIFIER option to OFF by default. You can change it with -I option.
Could it be that your stored procedure is now doing something on a table that has had an index added? I've had the same issue, and it's due to a new index on a computed column.
I have an application in classic ASP, and a database in SQL server 2005.
I transfer the database in SQL server express edition and I have one strange problem, I can see the tables in the database in this way:
information_Schema.dbo.test, so when I execute SQL command
select * From test
I get error that it can't find the table.
When I execute
select * From information_Schema.dbo.test
I do get results.
The problem is that my application is many many files and I can't rewrite the SQL commands.
Is there any way to find a solution in SQL without changing anything in my application?
I would guess you are not connecting to the information_Schema database but to some other db that does not contain the table. Did you put the table in the wrong place(Information_Schema doesn't sound like a typical application db location to me) or is your connection wrong?
We are using ODBC from C on Linux. We can successfully execute direct statements ("INSERT ...", "SELECT ...", etc) using ODBC for both SQL Server 2008 and MySQL. We are migrating to stored procedures, so we first developed MySQL stored procedures. Calling MySQL stored procedures using ODBC works. Life is good.
The stored procedures are translated into T-SQL. We verify that they function by executing queries directly from Visual Studio. The database is filled, queries work. Huzzah.
We have a test program allowing us to use MySQL or SQL Server, direct execution or calling stored procedures. We call the T-SQL stored procedures from a C test program. Log output indicates that tables are being filled with data, queries are working, etc. Until the end, where a statement fails. The program exits (taking several seconds longer than normal). The other 3 cases work (direct MySQL, direct SQL Server, stored proc MySQL).
We examine the SQL Server database. It's empty. We have autocommit turned on, so I don't think it's a commit problem. The stored procs are bog simple, being copies of the direct SQL. Any ideas?
It sounds like the query is running - then errors out for some reason, and everything is wrapped up as a single transaction - and rolls back. Hence empty tables.
Does the stored procedure have any error trapping within it? SQL Server 2005 and later improved error handling enormously with TRY.. CATCH.