I am trying to debug a stored proc in Visual Studio 2010. I need to be able to see data in temp tables I created by I do not know how to access that data during debugging.
How do I "dump" the values in a temp table when I am debugging through Visual Studio?
Pretty sure the answer is you can't. SQL Server doesn't allow you to access the contents of the temp tables when debugging. Your best bet is to do a SELECT INTO to a permanent table and then go from there. That's the only work-around I can think of.
Related
Good day, colleagues!
In our database all the stored procedures are binded to shemas, i.e.
Schema1.p_Procdeure1
Schema1.p_Procdeure2
Schema2.p_Procdeure1
But when I browse stored procs in Server Explorer in Visual Studio - it doesnt display shema names, i.e.
p_Procdeure1
p_Procdeure2
p_Procdeure1
It keeps sorting by schema names at first, but doesn`t display schema names! So, when you need to find exact procedure by name - you begin to suffer... Especially when there are tons of procedures...
Maybe anyone knows how to force displaying schema names in Server Explorer of MSVS?
It`s sad, but only now I noticed that schema name is displaying! But it is shown in the end of procedure name in brackets! (Unfortunately I cannot upload images)
So, the problem was in my wondrous inattention! I was looking for schema names for several hours and even started this topic!
But anyway, it will be much more comfortable and habitual if schema names will display in the begining of a string like in Enterprise Manager!
I'm using SSDT (in SQL Data Project) in Visual Studio 2013. When I publish the database, I can
Do a direct publish (click the publish button)
Generate the script, then execute in Visual Studio
But the script does pretty much nothing (apparently) if I copy it to SSMS and try to execute it (in SQLCMD mode).
How would I execute a generated script outside of Visual Studio? Do I have to use sqlcmd.exe? And if so, are there certain command line parameters that I would need to use?
Thanks!
The comment by Peter helped me look at the issue from a new angle. It wasn't a database problem, but a table issue. The database has an auditing table for every table. I was updating the Address table (I thought), but instead updated the A_Address table. It was all working fine. The first run updated the audit table, subsequent runs didn't (of course), but I was checking the Address table for the update. Doh! New database, new technology....
We want to start using the TFS version control on our project. I read the tutorial and noticed that TFS creates tables in the sql db. My questions are:
What are these tables for?
Where is the vs solution actually stored?
How can I use more then one instance of our solution from another computer (another developer)?
TFS stores pretty much all its data in few SQL database: source control, work items, build definitions, build results etc.
In the SQL database for the Team Project Collection, specifics about which tables etc should not matter to you. Users setup a workspace which maps the directory structure in source control to a place on their local disk.
I'm not sure what you're asking here, can you try clarify your question?
I'm generating domain model using LINQ to SQL via the VS2008 built-in editor. That works really well, too; when I adjust my database schema I simply delete everything from the editor and then pull it back in from the server explorer by selecting all tables and dragging them into the designer surface. That works great too.
Now the problem: I have properties that I manually set to autogenerated, readonly etc. using the property inspector on the right. Everything I re-create the entire schema I have to do this manually all over again.
Is there a way to persist these settings externally and/or automate them to bring it back to the state from before?
You can use something like the Huagati DBML Tools. This will allow you to update the DBML file from the VS designer.
I've also used the following process before:
Create my schema in SSMS
Create a script that uses the SQL Metal command line tool to generate the DBML file
As the DBML file is XML, you can run transformations on the file. I used this to simply change a few things like setting certain fields to be auto-generated (DateCreated, etc).
Then, either use SQL Metal or T4 to create the model files from the altered DBML file.
This process worked great - however I had complete control over the database schema. This process also allowed me to use L2S with SQL Server Compact Edition.
Hope this helps!
T4 Toolbox has a Linq to Sql Schema generator which allows you to develop your Linq to Sql applications in a model first approach. I have used it a little and it works really well, here is a blog post with details and usage info.
Your solution may appear to work when you have very few database entities / tables, but it does not scale and as you've found, syncing is less than ideal.
Do not use the Visual Studio 2008 LinqToSql O/R Designer
After looking at many alternatives to the problems you are describing with LinqToSql, I decided to abandon LinqToSql altogether as I didn't find any of the workarounds very good. Competing ORMs don't have the silly problems that LinqToSql has and they are much more mature and feature rich.
I could/should probably list some of the alternatives I ran across, but I don't want to spend the time and give you false hope, sorry.
II'd like to use Visual Studio to break whenever a record is inserted into a certain table, so I can see the values being inserted and the call stack from that moment. Is that possible, or am I stuck with stored procedure debugging only?
Well, since you're using SqlServer, why not just use Profiler? Set a trace, and you can watch the values insert there.... You can set up the breakpoint in Visual Studio, or you can just set it as a transaction that rolls back, then go through the trace to find the values that would have gone in.
If you haven't used profiler before, it's very easy and should do what I think you're looking to pull off.
Depending on how you are writing your code that is actually performing the database inserts, you could set a breakpoint on the function/sub that is being called and step through it to see the values that are getting passed through, but we would probably need to see more specifically how you are actually performing your database operations in your code.
Edit: As has been said, if you stay out of visual studio, using the SQL Server Profiler is probably your best option.
More effort than it is worth but is possible, could prob create a trigger on the table and use this method http://support.microsoft.com/kb/316549
But like everyone is suggesting, break on the .net code that does the insert or use sql profiler is much, much easier and reliable.