tags:

views:

382

answers:

3

I need to insert form data from my VB.NET application to a Microsoft Access database.

This is the syntax I'm using atm:

INSERT INTO bs1 (teacher, subject, date, period) VALUES ('test', 'test', 'test', 'test')

I'll admit I'm used to the MySQL type syntax, any help on this matter would be greatly appreciated thanks.

+4  A: 

I believe date is a reserved word. You need to encapsulate the reserved field names in square brackets:

INSERT INTO bs1 (teacher, subject, [date], period) VALUES ('test', 'test', 'test', 'test')

EDIT: See the following article for a complete list of reserved words in Access 2002 and greater: http://support.microsoft.com/kb/286335

~md5sum~

md5sum
+1 for noting that `date` is a reserved keyword. The user should also note the importance of using # to encapsulate the date, as pointed out by Remou above.
Ben McCormack
+2  A: 

In Access the delimter for literal values inserted into date fields is #, for text fields is ' or " and numeric field values do not have a delimiter, which suggests:

INSERT INTO bs1 (teacher, subject, [date], period) VALUES ('test', 'test', #2009-12-31#, 0)

Remou
Great observation in picking up the [date] field and using # to encapsulate it.
Ben McCormack
@onedaywhen, I deliberately said fields, because it is only when the field is of date type that date delimiters are needed.
Remou
@Remou: your wording could be improved: "the delimter for date fields" -- In Access Database Engine SQL, you don't need to delimit *fields*. The delimiters are required for literal values.
onedaywhen
@onedaywhen ok, you have a point, but your edit was not correct and in the number of years I have been answering questions in forums, it was a little more likely to confuse in that I have seen people trying to use date delimiters on date type data to be added to a text type field (column).
Remou
@Remou: thanks, then, for correcting my correction :)
onedaywhen
"numeric field values do not have a delimiter" -- which is a case in favour of explicitly casting literal values e.g. consider the implicit data types of these numeric literal values: SELECT TYPENAME(1E29), TYPENAME(1E28), TYPENAME(1E0), TYPENAME(1E-1), TYPENAME(1E-28), TYPENAME(1E-29)
onedaywhen
+1  A: 

In Access Database Engine SQL code, when you need to specify that a literal value is of type DATETIME, you can either explicitly cast the value to DATETIME or use # characters to delimit the value.

Using an explicit cast using the CDATE() function:

INSERT INTO bs1 (teacher, subject, [date], period) 
   VALUES ('test', 'test', CDATE('2009-12-31 00:00:00'), 0);

Using a DATETIME literal value:

INSERT INTO bs1 (teacher, subject, [date], period) 
   VALUES ('test', 'test', #2009-12-31 00:00:00#), 0);

When INSERTing a value into a column of type DATETIME, if you do not specify an explicit DATETIME value, the engine will implicitly attempt to coerce a value to DATETIME. The literal value 'test' cannot be coerced to type DATETIME and this would appear to be the source of your syntax error.

Note: none of the above applies to the NULL value. In Access Database Engine SQL there is no way to cast the NULL value to an explicit type e.g.

SELECT CDATE(NULL)

generates an error, "Invalid use of NULL". Therefore, to specify a NULL DATETIME literal, simply use the NULL keyword.

It pays to remember that the Access Database Engine has but one temporal data type, being DATETIME (its synonyms are DATE, TIME, DATETIME, and TIMESTAMP). Even if you don't explicitly specify a time element, the resulting value will still have a time element, albeit an implicit one. Therefore, it is best to always be explicit and always include the time element when using DATETIME literal values.

onedaywhen
Why was this voted down?
mgroves
@mgroves: when I see a down-vote without a supporting comment then I tend to suspect matters personal rather than programming -- you can always up-vote it yourself to redress the balance ;)
onedaywhen
This reminder concerning nulls helped me
datatoo