在MS Access Insert.Into期间解决“条件表达式中的数据类型不匹配。”

Question

I'm creating a basic customer inventory application, and when converting the code from using SQL Server to using MS Access (which I'm quite a bit less versed in), I ran into a "Data type mismatch" error when trying to do a basic insert.

I've looked into several similar questions here, and double checked the msdn syntax guide, but I can't find a reason why the script I've written would generate that error. I changed my code several times to try and ensure proper data type (ending up with what I have below with explicit typing and adding the value later). I've actually even taken the string and pasted it into MS Access (sans white space and double quotes), and it seems to work just fine with the values given. At this point, I'm really and truly stumped, and I'm wondering if it might just be a quirk with the Oledb adapter? Any help would be appreciated. Thanks.

// SQL query defined elsewhere:
public static readonly string sqlAddCustomerNotes = "INSERT INTO CustomerNotes (Customer_ID, Notes, NotesDate) "
            + "VALUES(@Customer_ID, @Notes, @NotesDate);";
// end sql query

// data access function
public static void addNotes(int customerID, string notes, DateTime notesDate)
        {
            string query = Scripts.sqlAddCustomerNotes;
            using (
                OleDbCommand dbCommand = new OleDbCommand()
                {
                    Connection = new OleDbConnection(ConnectionAccess.connString),
                    CommandType = CommandType.Text,
                    CommandText = query,
                    Parameters =
                        {
                            new OleDbParameter("@Customer_ID", OleDbType.Integer),
                            new OleDbParameter("@Notes", OleDbType.LongVarChar),
                            new OleDbParameter("@NotesDate", OleDbType.DBTimeStamp)
                        }
                }) // end using parenthetical
            { // begin using scope
                dbCommand.Parameters[0].Value = customerID;
                dbCommand.Parameters[1].Value = notes;
                dbCommand.Parameters[2].Value = notesDate;
                foreach (OleDbParameter param in dbCommand.Parameters)
                { // replace ambiguous null values with explicit DBNulls.
                    if (param.Value == null)
                    {
                        param.Value = DBNull.Value;
                    }
                }
                dbCommand.Connection.Open();
                int rowsAffected = dbCommand.ExecuteNonQuery();
                dbCommand.Connection.Close();
                Console.WriteLine($"Rows affected: {rowsAffected}");
            }
        } // end addCustomerNotes

/*
table "CustomerNotes" has the following columns:datatypes
    CustomerNotes_ID: AutoNumber
    Customer_ID: Number
    Notes: Memo
    NotesDate: Date/Time
    CreateDate: Date/Time

test case (in code) was:
    @Customer_ID = 5
    @Notes = "customer might change last name to simpson."
    @NotesDate = {6/26/2019 12:05:39 PM}
*/

Answer 1

它可能是一个日期 ，而不是一个时间戳 ：

new OleDbParameter("@NotesDate", OleDbType.DBDate)

Answer 2

Considering June7's comment about delimiters, it seems the issue lies in some issue inherent to the OleDbParameter type. In SQL Server terms, I do want DateTime (not Date ), but representing it as a DBTimeStamp seems to make it unrecognizable by Access.

For the time being, I've sent the date as a VarChar and allowed Access to convert it however its internal engine sees fit. It feels/seems wrong, but it does, in fact, solve the problem.

Parameters =
                        {
                            new OleDbParameter("@Customer_ID", OleDbType.Integer),
                            new OleDbParameter("@Notes", OleDbType.LongVarChar),
                            new OleDbParameter("@NotesDate", OleDbType.VarChar)
                        }

EDIT : Just saw June7's latest comment, and there was in fact, an answer in another thread . OleDbType.DBDate doesn't do what I want, but OleDbType.Date does.