The error message is what is created by the driver, that is, the Access client libraries - there isn't much that Perl can do.

Most likely it will help you to either increase the tracing level of DBI via

DBI->trace(99);
[download]

Often it also helps to simply print out the SQL before executing it. The SQL in question is in line 1 of some file you didn't who. 1 seems a weird line number, but that's what you tell us.

You are not interpolating variables into your SQL, are you? You should read up on placeholders and use those. That eliminates most types of syntax errors with your SQL.

I was using placeholders, ta. I tried the trace thing and got a lot more info but none of it useful. Having now gone into Access I've seen that's all it gives for error messages anyway! Thanks for the suggestion though. :-)

Although you haven't offered any details, "line 1" in the error message suggests to me that your SQL is being generated dynamically. Nothing wrong with that, in fact that's usually the whole point of having programs interact with databases. But my strategic advice to anyone starting out with DBI is to pratice first with a simple static SQL statement, your database's equivalent of print 'Hello, world!'.

Run a query through the MSAccess GUI, then view the underlying SQL and copy that into your Perl program. Get a feel for how DBI works by successfully doing something simple before you move back to the problem that prompted this post.

Then go the other way. Have your Perl program print out your SQL just before it executes it. Paste the printed out SQL back into the SQL view of the MSAccess query designer.

By all means come back to Perlmonks with questions about your results, and when you do, post some code.

Good luck!

Thanks, you're right, I was just hoping there'd be an easier way to do it from Perl itself, if you see what I mean? Having to open Access every time is a pain (esp. as I'm not very familiar with it). Looks like that's the only error message I'll get from Perl though.

I tried writing the query into Access normally and it changes it into something bizarre:

INSERT INTO tblCustomer ( LastName, BranchID, FirstName, Premise, Street, District, Town, County, PostCode ) SELECT 'a' AS Expr1, 'b' AS Expr2, 'c' AS Expr3, 'd' AS Expr4, 'e' AS Expr5, 'f' AS Expr6, 'g' AS Expr7, 'h' AS Expr8, 'i' AS Expr9;

The select thing seems slightly ridiculous. I wonder if that's just because the way the GUI works or whether Access databases themselves don't understand Values().

But anyway, that works. Thanks for your help.

I wonder if that's just because the way the GUI works

That's right. If you bypass the GUI (what Access calls Design View), you can run an INSERT ... VALUES statement against an Access database, just as DBI does.

Ask the GUI to display what you just did, and it converts the VALUES list to a SELECT clause without a FROM clause. If you don't want to see this happen, stay in SQL view.

Perhaps post the query here? More eyes looking at it will be able to find the syntax error faster.

Here's my query:

$sth = $dbh->prepare("INSERT INTO tblCustomer (BranchID, LastName, Fir
+stName, Street, Town, County, PostCode, PhoneNumber, Email, FAX, Note
+) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);
");

$sth->execute(
    'L1',
    $secondname,
    $firstname,
    $order->{addresses}->{delivery}->{street},
    $order->{addresses}->{delivery}->{city},
    $order->{addresses}->{delivery}->{county},
    $order->{addresses}->{delivery}->{postcode},
    undef,
    'rjberry@gmail.com',
    undef,
    'Order ID #' . $id
) or die "Could not update DB!";
[download]

(simplistic code, I know. I'm just writing a small program to transfer orders from the website to the EPOS system at the place I work ... )

I don't have MS Access to test this right now, but it could be that Access doesn't like the trailing semicolon at the end of your query.