Click here to Skip to main content
15,895,839 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
C#
private void button1_Click(object sender, EventArgs e)
        {
            SqlConnection con = new SqlConnection(@"Data Source=.;AttachDbFilename=C:\Users\Amit\Documents\ghf.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");

            SqlDataAdapter sda = new SqlDataAdapter(("create table  #xyz(pid int, pname nvarchar(50),pamount nvarchar(50),cid int,cname nvarchar(50)"), con);
            dt = new DataTable();
            sda.Fill(dt);   

           dataGridView1.DataSource = dt;
        }


SqlConnection con = new SqlConnection(@"Data Source=.;AttachDbFilename=C:\Users\Amit\Documents\ghf.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");
            SqlCommand cmd = new SqlCommand("insert into #xyz (pid, pname, pcost , cid ,cname) select  product.pid,product.pname,product.pcost ,category.cid ,category.cname  from product inner join category on product.cid = category.cid", con);
             
            SqlDataAdapter sda = new SqlDataAdapter(cmd);
            DataTable dt = new DataTable();
            sda.Fill(dt);
            dataGridView1.DataSource = dt;
Posted
Updated 23-Jul-15 2:47am
v2
Comments
Thanks7872 23-Jul-15 8:56am    
In such cases, its always better to also explain why you are doing all these.

The code doesn't quite make sense. In the first part you create a temporary table but use the command as a select. The create table command isn't returning anything.

Then again in the second you add to the temporary table using a select command and again use it like a select.

NOne of those commands will return anything to the client so it would make more sense to use SqlCommand.ExecuteNonQuery and forget the data tables.
 
Share this answer
 
Comments
sarvesh tharwal 23-Jul-15 9:43am    
being beginner...it's nice to be guided by people like you ... will u plz elaborate it by showing an example ... it'll be my privilege
Wendelius 23-Jul-15 9:47am    
What is it that you're trying to do? Are you trying to fetch some data to the client or something else?

If you're just fetching data, try to do it completely without temporary tables. In most situations they only make things more complex.
sarvesh tharwal 23-Jul-15 11:07am    
actually this #temptble is goin b used for customer's order in (cafe/hotel).selected data(snacks/items) from menu-table will b shown on that #temptble and that table will be used for an invoice or bill..... this #temptable will be invoke for the new customer......... is it right way to use #temptable??????????
Wendelius 23-Jul-15 12:02pm    
I wouldn't say so. I don't see any reason why you should be using temporary tables. When you store orders or bills etc you probably want to store them permanently. The data in the temporary table is lost when the connection is closed and I can't see why you would want that to happen.
sarvesh tharwal 23-Jul-15 13:08pm    
m using #temptble just to get the advantage of "commit" ,after committing this customer's order(which is in #temptable) will b fetched in another permanent table, and that table will be available to us to use it's data as historical data only
A temporary table is just that: temporary.
So when you create it on one SqlConnection, it isn't going to be available on a different one!
In fact, it's limited to the Session - so I suspect that it's only going to exist for the duration of the current Command. I've never tried to create a temporary table in one command and use it in a second, but I know it will be destroyed at the end of the SP that created it so I would suspect SQL server will destroy it when the command ends - even if it doesn't, that isn't behaviour I would want to rely on for future versions!

Personally, I'd write a stored procedure to create and then use the table so that the scope is clear and obvious.
 
Share this answer
 
Comments
CHill60 23-Jul-15 9:08am    
"I suspect that it's only going to exist for the duration of the current Command" - your suspicion is correct! I had to fix some code that had that problem a few years back
OriginalGriff 23-Jul-15 9:12am    
Nice to know - not that I'd want to do that anyway! :laugh:
CHill60 23-Jul-15 9:15am    
It's also nice to know that you agree with my eventual solution to the problem - the stored procedure! :-)
sarvesh tharwal 23-Jul-15 9:46am    
ohkk.. then.. i'll try it with stored procedures thank u very very much
OriginalGriff 23-Jul-15 10:23am    
You're welcome!
Yes, I completely agree with the suggestion in above 2 solutions. If you want to solve your problem then use the same connection object to deal with the temporary table as it is temporary with one connection. When you have created another connection then your temporary table will not longer be exist.

Do not initialize the connection object again and pass the same con object to second query where you doing insert into select.
 
Share this answer
 
Comments
CHill60 23-Jul-15 12:38pm    
See Solution 2 and the comments to it. The temporary table is per session, so it won't be available to the second query
sarvesh tharwal 23-Jul-15 12:56pm    
yupppp i got it...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900