I've been given an MS-Access application to maintain and being more acquainted with Oracle as dbms I bump into issues now and then..
Today it looks like MS-Access has problems when a hyphen is used for a column name...
The following insert statement was coupled to the NotInList event to add an extra entry to a listbox.
INSERT INTO tblProductInfo ( ProductInfo-Product )
"SELECT """ & NewData & """ AS ProductInfo-Product;"
But it's not working (anymore? first time the issue is reported, not sure if the original developer tested it out).
I've tested it out with a single-record append query and it looks like the hyphen is the culprit and I just cannot find a way to escape that..
INSERT INTO tblProductInfo ( ProductInfo-Product ) VALUES ("myData")
The error given is "Syntax error in INSERT INTO statement"
There does not seem any other way to specify the MS-Access fieldname, is it? (square brackets are only used for SELECT statements,
So... I'm calling for the wisdom of the Stackoverflow gods and am hoping someone knows how to solve this...
Thanks in advance !!
You need square brackets on that:
"INSERT INTO tblProductInfo ([ProductInfo-Product]) Values (""" & NewData & """)"
Or better yet, avoid odd characters and spaces in field and table names.
Square brackets are used in any sql statement where the field or table name is problematical:
It is a reserved word
It contains a space
It includes a special character
You can even use them with DDL:
Create Table tblProductInfo ( [ProductInfo-Product] Text(50))
Related
I have quite a strange problem, I'm very new to SQL and I was doing a free course in SQL
I'm actually learning the "SELECT" command.
So, I create my database, create some table, put some data in it with the "INSERT INTO" command
And now I want to select some data in it, but I have a strange bug (not an error) when i do
SELECT * FROM aliment;
everything work like it's supposed to do, but when I do
SELECT 'nom','calories' FROM aliment;
Something strange happens.
Instead have a list of all the specific data i'm looking to get i just get a list with all the data replaced by the name of the columns.
Here 2 screen to show you what's happens:
[2
I know one it's from the terminal(and yes it's not mine but from a video) and mine is from the software, but it's still had to work no?
You have a typo in your SQL. Use backticks (on the same key as ~ on a US keyboard) around your column names, not '. Using a single quote (an apostrophe) makes it a literal value, not a column name.
SELECT `nom`,`calories`FROM aliment;
I am trying to create a BCP file with | delimiter and then load it to a snowflake table.
Issue:
in SQL server there are columns defined as CHAR(4) and have values "sss"
so when i do BCP the its being padded to length of 4 "sss " and being loaded to snowflake
due to which our reports are failing because they do something like where column="SSS" but due to trailing space in snowflake the correct columns are not showing up.
we do not want to change our reports. So, is there a way that BCP can handle the padding or trimming of these columns?
note that there 24 tables and each have around 130+ columns so i cant go and put Trim functions on each char column
If your BCP file is maintaining the trailing space, then Snowflake will retain it, too, as long as the field is being FIELD_OPTIONALLY_ENCLOSED_BY a " or '. You may also want to make sure your TRIM_SPACE option is correctly set on your format definition for your COPY INTO command.
If your BCP file isn't maintaining the space and you can't figure out how to get that to work, you could force the space back in during the COPY INTO command with some string functions in your SELECT, or you could create a view for your report that does the same set of string functions to force the space for your report to work from.
So, is there a way that BCP can handle the padding or trimming of these columns?
Yes, but not by some switch or option. The correct way to handle this is to set your datatypes up front. As someone mentioned in comments to your question, your query that is creating BCP output should use VARCHAR(4) instead of CHAR(4). BCP is giving you what you asked of it. They way to avoid whitespace is to use varchar.
Seems like a fairly quick "find and replace" against scripted out query objects would work fine but you know your situation best.
Additionally, "trim" wont work - FYI. Even if the value of the field was only "SSS" (as in your example); if the result/column is defined as CHAR(4) you will get 4 bytes of data and a blank in the 4th place since you only had 3 bytes of data. Trim will work during the query... the padded " " you are getting is placed there by the copy out. The way to correct this is to set your data types as you need up front.
Unless someone knows of a better way in snowflake (im not familiar with it) the only other option is to manipulate the file inbetween SQL and Snowflake. replace " |" with "|"... but... blech.
This is a known "issue" with BCP. The "solution" is to use the queryout option, which means you must include a query with every export. But the data are the way they are.
Eg: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/88c258fe-d1a6-4f3a-9dac-40388d04e9c7/remove-space-in-columns-on-bcp-out?forum=transactsql
But this is really a Snowflake problem, because Snowflake has its own default CHAR semantics.
You get a warning in the documentation String & Binary Data Types but that doesn't tell the whole truth.
The following executed on Oracle (and apparently MSSQL? MySQL?) will select the aaa line:
CREATE TABLE C AS SELECT CAST('aaa ' AS CHAR(4)) t FROM DUAL;
SELECT * FROM C WHERE t = 'aaa';
but won't on Snowflake, unless you create the column with COLLATION:
CREATE OR REPLACE TABLE C (t CHAR(4) COLLATE 'en_US-rtrim');
INSERT INTO C VALUES('aaa ');
SELECT * FROM C WHERE t = 'aaa';
Unfortunately, you can't ALTER the collation after creation, which would have been convenient after a COPY INTO <table>.
PS: Mike Walton's answer is better, TRIM_SPACE is much cleaner than COLLATE.
Hello all you beautiful people,
To preface my question, we have a database that stores the entire HTML code of a web form (don't ask, I didn't create this) and some of those HTML values are populated from a different table. This table was discovered to have some double quotes (") in them, this is problem because if you have:
<input type="text" value="Hello "John" Smith">
It will break all of the tags below it.
We've gone ahead and fixed this, and I've implemented a solution to catch these from today onward. But now we have an unknown amount of forms that are broken.
So what I am trying to do is run an SQL statement to find all of the instances that this occurred.
Here is what I've got:
SELECT * FROM tableName WHERE data LIKE '%value="%"%"'
But this statement hasn't yielded any results.
Any help would be greatly appreciated!
Thank you,
DM
Your tags probably don't end with a quote, so let's add a wildcard at the end:
SELECT * FROM tableName WHERE data LIKE '%value="%"%"%'
If the value attribute is the last attribute in an element you could check if the value of value if enclosed in double quotes in this way:
SELECT * FROM tableName WHERE data
LIKE '%value="%"_%>'
The condition checks if there is double quote, before attribute value ends meaning incorrect value.
_% means one or more of any character.
I have been working on a database for my coursework and have used phpMyAdmin to build it. Now I am working on the queries using the query tool.
When I pick the tables and data I want to query and press "update query" it will generate the query which looks something like this:
SELECT `Customer`.`CustomerName`, `OrderDetails`.`Product`, `OrderDetails`.`QuantityOrdered`
FROM `Customer`
LEFT JOIN `Order` ON `Order`.`Customer` = `Customer`.`CustomerID`
LEFT JOIN `OrderDetails` ON `OrderDetails`.`Order` = `Order`.`OrderID`
This works fine and gives me the results I was expecting. However when I try and write my own query and put something like "SELECT Customer.CustomerName," WITHOUT the ' symbol it won't work and just throws up an error message.
Must I always wrap them using the ' symbol for the query to work?
Forward quotes are used to escape object names in MySQL. You don't have to use them unless you use names that wouldn't be valid identifiers - in this case, the table name order is a reserved word, and must be escaped. All the other tables and columns you're using seem to be OK.
Except for the visual nightmare and ability to create horrendous table names, backticks are entirely unnecessary. You will, however, be required to wrap any variables in single quotes.
As you can see from my example below, using backticks is not a requirement with PHPMYADMIN;
The reason it is not working when you remove the backticks is because you have a column called 'order'. Order is a keyword in SQL and therefore cannot be used as a column name without being wrapped in either quotes or backticks.
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;