My company has a legacy system that has run into a problem. The code is a combination of VB6, C# and SQL where the SQL consists of thousands of lines of in-line SQL pasted into a 'C#' application. Many temporary tables are created (and dropped). Finding the position in the code where a temporary table might be created or re-used is not easy (to say the least).
When run using SQL Server 2008 R2 the code behaves as expected. However, when running SQL Server 2014 or SQL Server 2016 one gets the error "There is already an object named '#whatever' in the database."
On the SQL Server 2014 database the compatability level on the database has been set as SQL Server 2008(100) and the MAX DOP (which I suspected to be the possibe source of the problem) has been set to 1.
Is there anyone who has experienced something similiar and if so is there any known workaround. The system is 25 years old and we want to retire the system, but there are those who simply love it too much.
The answer is actually amusing and simple. The developers used this function:
public static bool TemporaryTableExists(string TempTableNameWithHash, DataConnection mDataConnection)
{
return Convert.ToInt32(mDataConnection.GetValueFromSelect(string.Format("SELECT COALESCE(OBJECT_ID('tempdb.dbo.{0}'),0)", TempTableNameWithHash))) > 0;
}
The problem is the > 0. In SQL Server 2014 it seems that OBJECT_ID returns a negative value for a temporary table.
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 have a SQL Server DB that I want to script data for from a single table. When I try this I get the CyclicalForeignKeyException- presumably because somewhere there is an FK cycle, which is fine. This seems to be an annoying limitation of SQL Server, and in my case, I'm using SQL Server 2008 R2.
The 3 suggestions I've read for this are:
Get rid of the cycles. (Not an option as I don't want to modify this DB.)
Temporarily remove the keys and reset them afterwards. (Not an option for the same reason.)
Script all objects in the DB. (This would be possible, but this DB is large so this it not an ideal solution.)
Another similar suggestion I read was to backup the DB and restore a temp copy, remove the FKs, then get the data. But again since the DB is large, this isn't ideal either.
Any one have another idea?
Wow- I can't believe this worked...
I have a similar version of the DB I was trying to get data for on another machine. This time when I ran the tool it worked. (By tool I mean: Tasks->Generate Scripts... select 1 table, in advanced, change "Types of data to script" to "Data only".)
At first I thought this other version of the DB must not have the cyclical keys, but then I realized that I was using SQL Server Management Studio 2012 Express. So then I closed SSMS, did a runas /netonly with the domain user and opened SSMS 2012 and connected to the SQL Server 2008 R2 DB. I retried to generate the script and it worked!
Apparently SSMS 2012 fixed this "issue" and you can even use it against other DB versions!
I am developing an application in C# VS 2010 past 4 months. I used MS Access 2007 to store my nearly 20 tables successfully.
Today I realized that my data base cannot be handled consistently by MS Access 2007. Hence I decided to go for SQL Server 2008 R2 Express with Upsizing wizard and it worked really great!
However, when I tried to run various options of my already well developed application, It kept throwing error each time when a query is fired to SQL Server.
I understood that Many of the stuffs of SQL supported by MS Access are not supported by MS SQL Server
For example: query with date, for representing date format when we use '#', SQL Server 2008 won' t recognize it.
Also, for Bool value, MS Access stores it as True and False where as SQL Server uses 0.
These all queries worked perfect with Access 07
I am sure that there must be some method so that SQL Server can understand MS access queries.
Or will I have to edit my whole application?? It will be as good as digging a mine for earning gold..
I have changed all data access objects such as reader, adapter, command, connection to SQL data objects using System.Data.SqlClient.
So, It is not the problem.
Please help me asap.
Thank you.
You cannot force SQL Server to run the MS Access queries. These queries will need to be rewritten to use T-SQL instead of the query language that MS Access uses.
I feel your pain, I just had to rewrite a large MS Access application (over 1k queries) that needed to be recreated to be used in SQL Server.
There will be some queries that might be able to be ported over directly but as you noticed queries with date, and even some of the aggregate functions (First(), etc) are not used in SQL Server and those queries will need to be changed.
Here is a link with some info on converting Access to SQL
Converting Access Queries to SQL Server
You are right that, most of the time, you cannot just take the SQL of a query from Access and run it within SQL Server. It may work for very simple queries, but usually you need to tweak them.
There are a few steps I would take:
Extract your queries (which I presume are in your code), and re-create them in your Access database. Make sure they work there as normal Access queries.
(you can for instance simply add some code to your app to print all queries to files so you don't have to mess with parameters, then just copy/paste them in your Access DB).
The point is simply to have working queries within Access.
Use SSMA from Microsoft for helping you to move your queries to SQL Server. It does a good job of translating them into T-SQL.
You may still have to convert some troublesome queries by hand, but it shouldn't be that many and usually the conversion is not difficult.
Once converted to T-SQL, just re-inject these working queries into your code, or keep the complex queries in SQL Server as views (which it usually be faster as SQL Server will have already created its execution plan, rather than your application sending raw SQL that the server needs to analyse).
As you pointed out, there could be some issues if your fields use some features that don't cross-over to SQL Server properly.
Look at your tables in Access and do some cleanup before attempting to convert:
For booleans fields:
Make sure you set their default values to 0 or 1 (they should not be empty).
Required fields must be non-null:
Make sure that any fields that you have set as 'Required' does not contain any NULL values in its data.
Unique indexes cannot ignore Null:
Check that your indexes are not set to be both 'Unique' and 'Ignore null'.
All tables must have clean primary keys:
Make sure all your tables have a unique primary key that doesn't have Null values in their data.
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.]
I'm trying to replicate a rather large database from SQLServer 2000 to SQLServer 2008, located on two different servers. I found an article about attempting this and have been trying to follow its direction. Here is the article.
Mixed Mode Bi-Directional Transactional Replication between SQL 2000 and SQL 2008
Here is the part I'm stuck on:
"So, to create a publication, you will
need to NOT use the publication wizard
that you get in SQL 2008. Instead, use
a generated publication script and for
each sp_addarticle line that you have
in it, make sure that the #ins_cmd,
#upd_cmd & #del_cmd parameters point
to the appropriate stored procedures
and run it on the SQL Server 2000
server. Once this is done, go ahead
and create a subscription to SQL
Server 2008’s database normally."
I was able to get the stored procedures in place for all of the tables but need some direction on creating a generated publication script. Does anyone have some direction or a good example of a generated publication script?
On the final step of the publication wizard you will have the two options:
1. Create the publication
2. Generate a script file with steps to create the publication
The article referenced here is suggesting that you do not let the wizard create the publication but instead only choose to generate the script file. At that point you can edit the script file as instructed in the article.
You can run through the SQL Publication Wizard in 2008 and have it output to a script and then use that as a base model to modify with the appropriate arguments for the sp parameters listed in the question.
I'm just doing an upgrade of SQL 2000 to SQL 2008 R2 and I'm finding the publication wizard works just fine without any need to modify the scripts generated.
The article suggests creating some stored procs because it does not work bi-directionally out of the box. However, when it works brilliantly both directions, and very quickly too, just using the wizard. This is using SQL 2008 R2 which may be the reason, it may have improved since the original SQL 2008.