In SSMS and its immediate or locals window, is there a way to see the contents of table variable?
I can select and view the value of scalars, but I can't seem to find a way to query the contents of tables or even run
SELECT * FROM #someTableVarInMySproc
in the immediate window. Is there any way to do this?
No, sorry, this is not possible in current versions of Management Studio. It has been asked for, and it's been stated that they are considering something similar in a future version. You can vote and add constructive comments on the following items, though there is no guarantee they'll ever actually do it:
http://connect.microsoft.com/SQL/feedback/details/623353
http://connect.microsoft.com/SQL/feedback/details/582167
http://connect.microsoft.com/SQL/feedback/details/454870
http://connect.microsoft.com/SQL/feedback/details/363054
The first item in that list has an interesting workaround:
In addition to the obvious caveat that you may not be able to inject additional code to capture the data in an XML variable (because after all, if you can do this, you could also add old-school debugging techniques like SELECT * FROM #table), and the cumbersome nature of trying to read this information from XML, Management Studio 2012 crashed on me the first time I tried to do this - so if you're going to try it, make sure you do so in an isolated instance.
Related
Basically if I want to see what the data in a table/view looks like I use
select top 1000 * from ...
But this isn't too efficient for complex views or badly indexed tables.
I really just want to see what the data in a table looks like, e.g. the format etc.
Is there a better way to do this?
I'm using SSMS 2017
*Edit for clarification:
Badly written views are endemic throughout our databases so whilst fixing these is the obvious answer it's not really a realistic one.
I suppose i was hoping for a trick i wasn't aware of, because i understand using TOP puts some sort of order into it
If you highlight a table/view object in code and then press ALT + F1 in SSMS IDE it will execute the equivalent command of sp_help ‘object_name’ where object_name is the name of the highlighted object. Maybe this can give some quick information about the object you are interested in.
I'm attempting to create clean and professional looking queries for a college project, but for some reason a blank row starting with an asterisk appears at the end regardless of what I do.
So far I've tried a bunch of suggestions found on different forums, including setting the RecordsetType to "snapshot", and importing the file from a cleaned excel sheet, but so far I have had no luck.
The code for most cases is a simple SQL query such as this:
SELECT Table1.[Client Number], Table1.[Client Name], Table1.[Amount Paid], Table1.[Current Due]
FROM Table1;
Is the solution in the properties of my table/query, or is it perhaps within the code itself? I am VERY new to access, so forgive me if the question seems naive.
It should look like this:
but instead it looks like this:
I do want to reiterate that this IS for homework, but the question really has more to do with me wanting the output to look nice. (Which of course my Professor wants as well).
Any help at all would be greatly appreciated!
As far as I am aware, it is not possible to disable the data entry row when viewing the results returned by an MS Access query.
However, if you were to create a Datasheet Form whose Record Source is set to your saved query, then you can remove the blank row by setting the Allow Additions property to No within the properties of the form:
I am working on converting an Access database to a SQL Server backend. I've got most of it working, but one thing I haven't been able to figure out yet is that on one of the reports that we run, a few fields show up as #Error! The field's Control source is:
=DSum("[CustomerMinutes]","QryOutageSummaryByDateRange","NZ([CityRelated])= 0")
It works fine as shown, but it takes a lot longer to load the report and the CityRelated field is a not null field, so I feel as though I shouldn't need to use the NZ() function. I have opened the query in datasheet view and there appropriately isn't any NULLs. I would be more than happy to provide more detail, I just don't know what other information I should provide. Any help or general direction would be greatly appreciated!
The database function (DSUM, etc.) are fussy about the use of brackets. Try this.
=DSum("IIF([CustomerMinutes] Is Null,0,[CustomerMinutes])","[QryOutageSummaryByDateRange]","[CityRelated] Is Null Or [CityRelated]=0")
If CustomerMinutes is never NULL then you can just use CustomerMinutes as the first argument.
Notice that the square brackets are around the table or query name, not necessarily required for a single field-name. (This is the opposite to the how the examples appear in the Help system.)
I always prefer to avoid NZ - it can, in my experience, cause problems with aggregate functions, or when used in a sequence of queries.
I had created a new stored procedure from an existing one. all I did was copy the old one and changed the name.
Now when i run both in the query analyzer, i get data from the original but the new one does not return any data.
It could be with permissions but both are set to public. Any thoughts?
check ansi-nulls value? they can casuse a headach. hard to tell without seeing the code but as a general debug rule; break it apart into its basic queryies and see where the issue is introduced or where it starts to diferentiate from results of the original stored sprocedure
Sorry if my question appears naïve, but... how did you actually make the copy?
I have only used SSMS to work with DBs so far and am oblivious of other interactive tools, if there are any. As to SSMS, a mere replicating is often done in this scenario: sp_helptext [proc name], then copying the output into a new query window, changing the name and voila (i.e. 'executing the script'). The permissions are peeked at in the original proc's properties and usually added using the same or a new script.
It seems so trivial that I feel a bit guilty to put it here. Anyway, that method has never failed me so far. What is yours then?
Sorry, this of course doesn't answer your particular problem with the already copied SP. I just thought maybe you wanted some help in the more fundamental problem of its replicating.
Creating script and re-replicating the sp worked. it could have been the proc's owner or permissions related. dont feel like debugging any more after I got that working.
I'm at a client doing some quick fixes to their access application. It was a while I had a go with access, but I'm recovering quickly. However, I've discovered an interesting problem:
For some reports, I get a "Record is deleted" error. I've checked the reports, and it seems like there's a problem with one table. When opening that table, I find a record where all columns are marked "#deleted". So obviously, this row seems to be the culprit. However, when I try to delete that row, nothing really happens. If I re-open the table, the row still exists.
Is there a corruption in the db? How can I remove this record for good?
Edit: It's a MS2000-version
Solution: Simply compress/repair did not work. I converted the database to the 2003 file format instead, which did the trick. I've marked the first answer suggesting compress/repair, since it pointed me in the right direction. Thanks!
Have you tried the built in Access compact/repair tool? This should flush deleted records from the database.
The exact location varies according to the version of Access you're running, but on Access 2003 it's under Tools > Database Utilities > Compact and repair database. Some earlier versions of Access had two separate tools - one for compact, one for repair - but they were accessed from a similar location. If they are separate on the version the client has, you need to run both.
This should be a non-destructive operation, but it would be best to test this on a copy of the MDB file (apologies for stating the obvious).
Tony Toews, Access MVP, has a comprehensive guide to corruption:
Corrupt Microsoft Access MDBs FAQ
Some corruption symptoms
Determining the workstation which caused the corruption
Corruption causes
To retrieve your data
As an aside, decompile is very useful for sorting out odd happenings when coding and for improving start-up times.
you can also try this Command line utility
//andy
Compacting and importing won't fix the problem for the error reported, which is clearly a corrupted pointer for a memo field. The only thing you can do is delete and recreate the record that is causing the problem. And you need to find ways to edit memo data (or eliminate memo fields -- do you really need more than 255 characters or not?) that does not expose you to corruption risk. That means avoiding bound controls on forms for memo fields.
Instead, use an unbound textbox, and in the form's OnCurrent event, assign the current data from the form's underlying recordsource:
Me!txtMyMemo = Me!MyMemo
To save edits to the unbound control, use the control's AfterUpdate event:
Me!MyMemo = Me!txtMyMemo
Me.Dirty = False ' save the whole record
Why are memo fields subject to corruption? Because they aren't stored in the same data page as the non-memo fields, but instead, all that is in the record's main data page is a pointer to some other data page (or set of data pages if it's a large chunk of data) where the actual memo data is stored. If it weren't done this way, a record with a memo in it would very quickly exceed the maximum record length.
The pointer is relatively easily corrupted, most often by a fatal problem during editing in a bound control. Editing with an unbound control does not eliminate the problem entirely, but means that the time in which you're exposed to danger is very, very short (i.e., the time it takes for those two lines of code to execute in the AfterUpdate event).
Aside from the options already posted above, I've used another simple method aswell: Simply create a new MDB file and import all objects from the corrupted one. Don't forget to get system and/or hidden objects when you go this way.