Recently I have been using Microsoft SQL for creating databases that are referred to using an excel document. There have been a number of instances when I needed to make a small changes to my tables and ended up "DROP"-ing all my current tables and re-creating them using an updated query. I understand you can use UPDATE to change the values of records within a table, but I'm looking to manipulate a data type so that I can change the number of decimals in one record of my tables from 2 to 3. Code for creating the table looks something like this:
CREATE TABLE WIRE_INDEX
--"Field" "Data Type" "Null or Not"
(...
...
DENSITY decimal(18,2) Not Null);
I don't know if the solution is something obvious, but I have been unable to find anything useful. I'm not sure know how to refer to the data type of a field in SQL.
When I populate the database I use numbers like 0.283 and 0.164, but when I SELECT the record I only get the first two decimals. I'd like the first 3 decimals to appear in the way I enter them into the table.
(edit didn't show up properly)
(not sure if I'm supposed to post my solution), but credit to TEEKAY and Apurav for answering my question. I used the code posted by Apurav which looks like this:
ALTER TABLE WIRE_INDEX
ALTER COLUMN DENSITY decimal(18,3) Not Null
When I pulled the table, using a SELECT statement the precision showed three decimal places, but I lost the precision of my input and had to re-enter my values using UPDATE. Not sure if this is more effective than just starting over, but it worked for me and now I know.
I have a SQL server-backed Access database, and I'm struggling with one of my tables, "Notes".
My database has a Profile form for each user, and on their profile, I want to display notes from the Notes table. My notes table is set up like this:
NoteID (PK) int
GoerID int
NoteType int
Note (????)
StaffID int
Timestamp datetime
My issue is with the Note format. I can get a query to pull all information, but when I try to use a listbox to display the query info, the Note field is NOT available to add to the listbox.
I'm sure it's likely this is due to the field type, but I've tried every type I can think of. ntext, text, nchar, etc. Basically, I need this note field to have around 200 characters of variable text and be displayed in the listbox.
Any help would be appreciated!
Thanks
Updated with screenshot of table and datatype settings in Manager Studio:
Screencap
Also note that I've rebuilt the table several times (when changing datatypes), and in the screencap, the NOTE field is actually named [NoteText]
Use varchar(255) or (if you need Unicode) nvarchar(255).
That will translate into Text(255) (resp. Short Text in newer Access versions) on the Access side, and will work with your listbox as well.
Background: In a Java application I'm working on, I'm doing a refactoring of the storage of enum values. Previously, these were stored as integers, and mapped through enum values with a helper method in the enum. I would like to utilize the #EnumType.STRING capabilities of JPA to make the database more readable.
So, what I'm basically trying to do is change the type (as well as the values) of a column. For example, I had this table definition to begin with:
table Something (
id int,
source int,
[more columns]
)
I wanted to change the source-column into a VARCHAR(100) column instead, and here is how I did that:
Introduce a new column, called source_new with VARCHAR(100).
Populate the new column with mapped values based on the values of the old column (so each row with value 1 in the source column get's the value 'SomeSource' in source_new, each row with value 2 in source gets 'OtherSource', and so on
Drop the source-column
Rename the source_new column to source (using sp_rename)
My problem is this: Once this is done, I can't update the now newly defined source-column, because it still insists that it's an int column, and not a varchar column!
So a query like this:
update Something set source = 'SomeSource' where id = 1;
fails with this:
Error: Conversion failed when converting the varchar value 'SomeSource' to data type int.
SQLState: 22018
ErrorCode: 245
At the same time, sp_help of the table shows that the column is defined as varchar(100), and not int! Also, the column holds numerous varchar values from the original datamigration (from before the rename).
Is this a bug, or am I doing something wrong by renaming a column to a column name that was previously used with another type? (And as I'm typing the last question, it just sounds absurd to me, when I drop a column I expect to disappear, not to leave traces and in effect not allowing me to reuse the column name at any time in the future..)
SQLFiddle to illustrate (sp_rename doesn't work with SQLFiddle it seems): http://sqlfiddle.com/#!3/0380f/3
I have found the culprit, and it's name is trigger!
Some genious decided to put a check if the value updated is a valid source (checking against another table) in a trigger, so much for trusting your own code..
I spit on the shadow of people who hide functionality in database triggers, pfoy! Go back to the 80's where you belong! :p
I am updating a table in a .mdb format Access database with Access 2013. I want to add a new field, lets say a Description field, to an existing table.
I can add a text column using the following query
ALTER TABLE TestTable ADD Description TEXT(255);
Alternatively I could use
ALTER TABLE TestTable ADD Description varchar(255);
This works fine, and adds a column to TestTable called Description that is limited to 255 characters. If I open the table in Design View, I can see that the type of Description is listed as "Short Text". However, there is an option there to have the field be of type "Long Text" which as far as I can tell doesn't have a character limit. It is easy to manually change the type from the Design View, but I want to know if I can do this via a query.
I tried increasing the character count in my original query like so
ALTER TABLE TestTable ADD Description TEXT(300);
But then I recieve the error "Size of field 'Description' is too long."
What I want to know is can I add the column via a query such that it has a character limit greater than 255? This query is run as part of a macro that is run automatically, so I don't want to have to change it manually. My attempts at searching for a solution via Google have so far come up empty.
Found the answer shortly after posting the question. Using the query
ALTER TABLE TestTable ADD Description LONGTEXT;
creates a new column of type "Long Text". It should be noted that a character count was not necessary for this type.
I have just created an SQL Server 2005 SSRS report and the data is not being displayed in the Preview pane.
The dataset is correctly populated from a stored procedure against a String parameter. I can execute it in the Data pane. When running the report in the Preview pane the correct number of rows are displayed but the contents of the cells do not contain any data
The source dataset is based on a Stored Procedure with a passed in String parameter in SQL Server 2005 that return the contents of a temp table. The dataset then maps the fields to locals. I can execute this correctly in teh Data view.
Stored Procedure
ALTER PROCEDURE spWebReportStage25BuildReview
#BuildNumber as nvarchar(50)
Temp table schema
CREATE TABLE #tmpModelZones
(
BuildID bigint NOT NULL,
BuildNo nvarchar(50) NOT NULL,
ModelID int NOT NULL,
ModelName nvarchar(50) NOT NULL,
ZoneID int NOT NULL,
ZoneName nvarchar(50) NOT NULL,
SortOrder int NOT NULL,
Created bit DEFAULT 0 NOT NULL,
Closed bit DEFAULT 0 NOT NULL,
PRIMARY KEY (BuildID, ZoneID)
)
SSRS Dataset
SSRS Dataset mapping
SSRS Dataset Parameter
Executing Dataset with parameter
There are no additional grouping, filters or aggregation on the displayed table. It is simply a flat table
Never seen this before. However, SSRS can be a bit "off" at times, so here's a list of things to try. I'm afraid most of these are of the type "Have you tried turning it off and on again?".
Delete the .data files associated with the report.
Duplicate/back-up the report, and try to add the dataset in a fresh, basic tablix to see if that does show data.
Check the hidden property. Don't forget that (for some stupid reason) it's not (like in any other sane product) a Visible Y/N field, but a Hidden Y/N field.
Double check font color and size, etc.
Run the report on your reportserver (as opposed to the preview) to check if that does work.
Use some temporary text boxes to show the actual values of your parameters, to check if they are exactly the same as when you test-run the data set.
Check the code-behind (xml in the rdl) for unexpected filters, hidden property, expressions, etc. in the tablix. Even if you can't quite "read" the RDL, with syntax highlighting you should be able to skim it and extract a lot of info on this.
Check the ExecutionLog2 and other logging stuff to see how many rows are being returned in report runs.
In addition, it would help if you update/edit your question with some more info:
What kind of groupings does the tablix have?
What are the filters on the tablix, row groups, and column groups?
What is the general structure of the dataset, and it's results?
How are the parameters structured and used?
When using temporary tables, SSRS fails to get the metadata. So there are basically 2 ways of letting SSRS know the column names:
Add SET FMTONLY ON. This will retrieve the metadata but it won't display the data.
Go to the DATA tab and click on the Generic query designer and click refresh fields. This will prompt a dialogue box for specifying the parameter value. When we run the query in query designer SSRS gets the schema and the data from the stored procedure. Now the data will be available in preview pane.
I also had a similar issue. In my case, it even occurred without any parameters or anything, just the most simple report you can imagine. It included a table with a single field, no filters were used. I did manage to view some data, but only those lines were shown which did not fit into the cell and thus forced the row height to increase.
My fix for this issue: changing the font or the font size from the standard (size 10, Segoe UI). Then, all data was showing. Changing this back to Segoe UI made the data disappear once again.
I had the same problem. Here is what I found. Here is my code:
DECLARE #tblPigProblems TABLE (
Id INT IDENTITY,
PPId INT,
GaugeColor VARCHAR(25),
FullStartTime VARCHAR(25),
PigSystem VARCHAR(25)
)
IF (1 = 0)
BEGIN
SELECT * FROM #tblPigProblems
END
...
SELECT '#tblPigProblems' [PigProblems],
#p_vchLine [Line],
GaugeColor [Product],
FullStartTime [Start Time],
PigSystem [Pig System]
FROM #tblPigProblems
What I did was to use the initial "SELECT * FROM #tblPigProblems" to ensure that if any error messages were specified in the code before the final select statement returning the dataset, that SSRS was able to determine the fields from the stored procedure. Then, when the results were determined, I assigned an alias to the fields. The problem was that the aliases for the fields did not match the declared field names (ie: the declared field "GaugeColor" did not match the alias "[Product]" I supplied in the select to create the result set. The way that I realized this is that when I refreshed the fields in the Data section of the SSRS report, then displayed the dataset fields, it listed the field names from the table declaration (ie: "GaugeColor"). When I executed the stored procedure within the dataset (clicked on the !), the result set listed in SSRS showed the field aliases (ie: "Product"). Since these didn't match, nothing was displayed in the textbox I had assigned the field to (ie: "=Fields!ColorGauge.Value"). SSRS did not pick up this discrepancy and allowed the report to be created, but no values to be displayed. The fix was simple, replace:
IF (1 = 0)
BEGIN
SELECT * FROM #tblPigProblems
END
with:
IF (1 = 0)
BEGIN
SELECT '#tblPigProblems' [PigProblems],
#p_vchLine [Line],
GaugeColor [Product],
FullStartTime [Start Time],
PigSystem [Pig System]
FROM #tblPigProblems
END
Dan
I had a case where a working report stopped displaying data. I added another table with no formatting, linked to same dataset - verified that the query no longer returned data when passed parameters by SSRS. After investigating, I noticed that my test parameter for a "anchor date" value was formatted as YYYY-MM-DD, and in my updated query, I was making assumptions about the order of the characters in the date parameter (to truncate to YYYY-MM for one join).
I suspected that SSRS may be passing the date in a different format (MM/DD/YY being my current cultural setting for date defaults). So running with that hunch, I changed my SQL logic to work with any date format passed. - e.g. left(convert(date, #anchorDate, 20), 7)
This fixed my problem - the format assumptions that I had tested with (hard coded values to test the query while developing) were bad assumptions. SSRS can pass data in local formats as well - so be sure to watch out for this kind of assumption.
I had the same problem and I tried to check the priorities of my tablix. I solved the problem by changing CANGROW value to FALSE.