Linq To SQL - Getting Empty Brackets - linq-to-sql

When i view the Linq to SQL value i found thos
[t0].[] AS [Stamp]
this should be
[t0].[Stamp] AS [Stamp]
My Question is why this could happen?
The error i get because of this is:
An object or column name is missing or empty. For SELECT INTO
statements, verify each column has a name. For other statements, look
for empty alias names. Aliases defined as "" or [] are not allowed.
Change the alias to a valid name.

Just in case someone go through this. It all started when i added a column manually to the dbml file.
I missed one property.
I looked again to the Stamp field in dbml and found that i missed to fill the Source Property.
Thanks

Related

SSIS REPLACE Function - Derived Column

I have a variable with a value of '1617'. It is a DT_WSTR datatype currently. Sometimes I need a string, others an integer.
I am using a derived column to replace the ' values so that I can cast this value as an integer.
My replace function is not working.
REPLACE([User::schoolYear],"'","")
What am I doing wrong?
The problem with your supplied expression, is that you are not referencing the variable schoolYear. Sometimes, you can address a variable as #schoolYear but the consistent, explicit syntax I would encourage is #[User::schoolYear] That way, you can identify the namespace in case someone like me has used a custom namespace.
Your Derived Column expression then becomes
REPLACE(#[User::schoolYear],"'","")
You are having space before and after the single quote, which is causing the replace to fail.
Modify the expression as given below. I have tested it. It is working fine.
REPLACE([User::schoolYear],"'","")

Getting Syntax error using Microsoft Access

I keep getting a syntax error using Microsoft Access. I believe I am putting in the iif statement incorrectly. I am even using the expression builder. However, it keeps saying that there may be a misplaced comma
Please help
Respectfully,
In Design View instead of , use ; in the IIF() function:
IIf([LastName]="Smith";1;0)
If you see the query in SQL View though, you will see the function with commas.This is a case applying to regions where the comma could be a decimal separator (check your regional settings of your PC).
The error is not due to the use of the comma in place of a semi-colon, but rather because you have set the Table row to Orders within the query grid:
As such, the query is attempting to access a field called [iif([LastName]="Smith",1,0)] from the table Orders, and this is an invalid field name.
Since you are using a calculated field which isn't being sourced directly from any particular table, clear Orders from the table row for this field to fix the error.

Syntax error in date in query expression for non-date fields

I'm having trouble building a query in Access 2013. The database isn't mine and the only thing I really have control over is this query. There is a table, I'm pulling 7 fields from it and eventually adding an 8th field to the query to do some string manipulation.
However, I keep getting getting "Syntax error in date in query expression 'fieldname'." error whenever I click on the arrow to sort the fields. The odd thing is these errors pop up when sorting non-date fields. When sorting the date field I get "Syntax error (missing operator) in query expression 'Release Date'."
This happens after a fresh build. I have no WHERE conditions, just SELECT and FROM. Ideas?
Here's the sql query, though I'm mainly working in the query design view:
SELECT Transmissions.[Job#], Transmissions.[Part#], Transmissions.TransmissionSN, Transmissions.Status, Transmissions.[Release Date], Transmissions.[Build Book Printed], Transmissions.[ID Tags Required]
FROM Transmissions;
Well... it seems you are the lucky inheritor of a poorly designed database.
Using special characters in a field name is just asking for trouble. And you've found what that trouble is.
Access uses the # sign to designate a Date type for query comparisons. Such as:
dtSomeDate = #2/20/2017#
You surround the date with the # signs.
In your case, the query thinks [Job#] and [Part#] are trying to wrap dates. But of course, that's not the case and thus it fails.
You can try a couple of work arounds. (I leave it to you to experiment.)
1) You can try to rename the problem fields within your query. So that:
Transmissions.[Job#] becomes Transmissions.[Job#] as JobNum
and
Transmissions.[Part#] becomes Transmissions.[Part#] as PartNum
2) You can try to copy the [Transmissions] table to a new table that you create
that does not have the naming problems.
3) Export the [Transmissions] table to a CSV file and re-import it to a new
table (or possibly new database) without the naming problems.
Here is a link to a microsoft article that tells you why to avoid special characters in Access:
Big Bad Special Chars.
Hope that puts you on the right track. :)
Typically, this means that the field names are missing or misspelled.
Try running this to see:
SELECT * FROM Transmissions;

How do I capitalize all text in a column of data in an Access Query while keeping the name of the field the same?

How do I capitalize all text in a column of data in an Access Query while keeping the name of the field the same?
I tried entering "SPEC: StrConv([SPEC],3), but I get an error that I have a circular argument (which, isn't too surprising). So how do I get around this?
Is there a totally different approach to capitalizing in queries?
Given: we have a field named [SPEC].
Problem: need query to grab [SPEC] and convert it to all caps, but
with the same field name
Added: We will call the table that holds the field [SPEC],
[tblTable]
Solution:
What we need to put in the query builder is the following:
SPEC: UCase([tblTable].[SPEC])
That way the machine can figure out that Query.SPEC isn't the same identifier as tblTable.SPEC
Equivalently:
SELECT UCase([tblNames].[FirstName]) AS FirstName
FROM tblNames;
How about using the Ucase function
Ucase(String)

SSIS ISNULL to empty string

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.