I am trying to enter a default value of a string row in my database, using ASP.NET Visual Studio. I am simply trying to have "NotSet" as default but I get this error when trying to update the database:
The name "NotSet" is not permitted in this context. Valid expressions
are constants, constant expressions, and (in some contexts) variables.
Column names are not permitted.
I still have trouble understanding what kind of values are permitted, though. The datatype is "nchar(10)" and nulls are allowed. There's nothing else to it.
Make sure NotSet is in quotes in your sql statement
'NotSet'
Related
Should I exec directly (pseudo code)...
q = "CREATE TABLE `usermood` { `id` INT, `name` TEXT, `mood` VARCHAR DEFAULT 'gloomy' }";
exec(q);
...or bind to a (un)named placeholder?
q = "CREATE TABLE `usermood` { `id` INT, `name` TEXT, `mood` VARCHAR DEFAULT :mood }";
prepare(q);
bind(q, ":mood", 'gloomy');
exec(q);
I've never seen it in any example code.
It's less about the security of escaping (because I control the create statements) but rather about converting the value into a database compatible format (automatic selection of content representation by type).
I'm using MySQL as well as SQLite3.
Are there database drivers that don't support binding in create statements?
If anyone is interested: I'm using QSqlQuery with QVariant as value.
You would use parameter binding when:
You are using a value from an unknown source, and you want to protect against SQL injection.
You want to prepare a statement and execute it repeatedly using different values for the parameter.
Neither of these is likely for your CREATE TABLE example.
I have never used a parameter in any DDL statement.
P.S.: You can't set a DEFAULT for a TEXT column regardless of whether it's a bound parameter or a literal value in the DDL statement, but I'm guessing your example above is artificial.
SQLite explicitly forbids binding default values:
from the SQLite docs:
An explicit DEFAULT clause may specify that the default value is NULL, a string constant, a blob constant, a signed-number, or any constant expression enclosed in parentheses. A default value may also be one of the special case-independent keywords CURRENT_TIME, CURRENT_DATE or CURRENT_TIMESTAMP. For the purposes of the DEFAULT clause, an expression is considered constant if it does contains no sub-queries, column or table references, bound parameters, or string literals enclosed in double-quotes instead of single-quotes.
(emphasis by me)
I'm using SSIS to separate good data from unusable date. In order to do that I used derived columns, script task and conditional split where I assigned certain conditions. One of the conditions I need to apply is that none of the numbers in one column cannot be negative. I'm guessing that the best way to solve this would be using conditional split, but I cannot get it to work. I'm new to SSIS, so any help would be appreciated.
You'd have an Expression like
[MyCaseSensitiveColumnName] < 0
and then name the output path something like BadData_NegativeValue
From the comments
that is what I did before, but I'm getting an error saying that The data types "DT_WSTR" and "DT_I4" are incompatible for binary operator ">"
That error message indicates that you are attempting to compare a unicode string (DT_WSTR) and an integer (DT_I4) and that the expression language does not allow it.
To resolve this type incompatibility, you would need to first convert the value of MyCaseSensitiveColumnName from DT_WSTR to an integer.
I'd likely add a Derived Column Component to my data flow and create a new column called MyCaseSensitiveColumnNameAsInteger with an expression like
(DT_I4) [MyCaseSensitiveColumnName]
Now, that may be perilous depending on the quality of your source data. I don't know why you are pulling numeric data in as a string. If there could be non whole numbers in the data set, then we will need to check before making the cast. If there are NULLs in that dataset, those too may cause issues.
That would result in our conditional split check becoming
[MyCaseSensitiveColumnNameAsInteger] < 0
I'm building a PHP/HTML front end to a MySQL database.
The table I'm attempting to work with defined with a column that is varchar(15). I can run (without error) an insert statement with a character string that is 20 characters long. The resulting record's column is truncated to 15 characters, but no error is generated.
How do I get this to generate an error?
I know that the interface can do the error checking, but I want to know how to get the database to reject the data as well.
MySQL's fairly forgiving and will try to gracefully accept anything you pass it as best you can, silently converting/truncating/nulling if need be.
Since you don't want that, you need to enable the various "strict" mode options: http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html
So I am currently working on a migration from an old Advantage database server to SQL 2005 using SSIS 2008. One of the columns in the old Advantage database is a MEMO type. By default this translates to a DT_TEXT column. Well in the new database I do not need this large of field, but can limit it to something such as VARCHAR(50). I successfully set up a derived column transformation to convert this with the following expression:
(DT_STR,50,1252)[ColumnName]
Now I want to go a step further and replace all NULL values with an empty string. This would seem easy enough using an ISNULL([ColumnName])?"":(DT_STR,50,1252)[ColumnName] expression, but the problem is that the OLE DB Destination contains the following error
Cannot convert between unicode and non-unicode strings...
So apparently the whole ISNULL expression converts the data type to Unicode string [DT-WSTR]. I have tried a variety of casts upon the whole expression or different parts, but I cannot get the data type to match what I need it.
First, is it possible to convert the DT_TEXT type directly to unicode? From what I can tell, the casts don't work that way. If not, is there a way to get an expression to work so that NULL values get converted to empty strings?
Thank you for all your help!
Give this a try in your derived column.
(DT_STR,50,1252) (ISNULL(ColumnName) ? "" : (DT_STR,50,1252) ColumnName)
It includes an additional type cast with the Conditional (?:) in parentheses to ensure the desired processing sequence. I think your original expression was implicitly casting to DT_WSTR because the "" defaults to DT_WSTR. With this new version, you force the cast to DT_STR after the expression is evaluated.
I figured something out that works. It may not be the best solution, but it will work for my situation.
From my OLE DB source I first did a Derived Column. This I used the ISNULL which ended up converting it to a DT_WSTR unicode type. although I could not get any casts to get it back to the type required, I then added a Data Conversion transformation in-between the Derived Column and the OLE DB Destination. This would take the input string and convert it back to a DT_STR. This all feels a little annoying converting so many times, but the column does not contain any funky information that I should have to worry about, so I suppose it will work.
Thanks for all those who pondered the solution, and if you find some awesome way to tackle it, I would be more than interested.
I'm trying to create a simple 'yes'/'maybe'/'no' Enum in MySQL with PhpMyAdmin
I set NULL to No, and 'maybe' as the default value
I am expecting an error when executing something like "SET EnumCol=''", because '' (an empty string) should not be a valid value.
But the query gets executed and the value gets set to '' - which means I'm forced to double check for this unwanted and illegal value whenever I read from the database!
Is this a bug in MySQL or PhpMyAdmin?
Does anyone know a way of disabling this behavior?
Thanks.
Empty string is error indicator of invalid values in ENUM. From mysql ENUM type manual:
If you insert an invalid value into an ENUM (that is, a string not present in the list of allowed values), the empty string is inserted instead as a special error value. This string can be distinguished from a “normal” empty string by the fact that this string has the numerical value 0. More about this later.
To disable this behaviour:
If strict SQL mode is enabled, attempts to insert invalid ENUM values result in an error.
To enable strict mode see Server SQL Modes.
ENUM's are a pain in the butt. unless you also need to set the value by a number, i would stay away from them.
instead, use a varchar column with a foreign key to a lookup table to restrict the values. that will make it impossible to insert a bad value.