Error "SELECT statement includes a reserved word"

Question

Dear Sir,
I am developing Ms Access 2010 and XP is the operating system.
I have placed a combobox on a form, but when I tired to update new string value in the same combobox, it generates  an error "The SELECT statement includes a reserved word or an argument name that is misspelled or missing, or the punctuation is
incorrect." .
I have debuged "Not In List" event and find  this error generates soon after completing the "Not In List" event. I tried to find out any help on the internet but failed.
I shall be ever grateful if some one could help this regards.
Kazim

Answer 1

I think you need to do some homework on how relational databases work. 
The following is my short description of the database relational model, but I emphasise the word 'short'. 
The subject is a complex one with a huge body of academic and technical literature, so I can only hope to touch upon the basic principles of the model:
"The database relational model was originally proposed by E F Codd in a paper in 1970 in the journal 'Communications
of the Association for Computing Machinery'.  Since then there has been a vast amount of further theoretical work, and the relational model has shown itself to be a robust one. 
Without going too deeply into the theoretical basis, which can be quite abstract, a relational database in essence models a part of the real world in terms of its entity types and the relationship types between them. 
Note the inclusion of the word 'type' in both cases here. 
While its almost always used in the former case, its often omitted in the latter case. 
This is a little bit sloppy but not too important.  When one talks about a 'relationship' it really refers to a relationship value. 
As an example 'marriage' is a relationship type, but my being married to my wife Fiona is a relationship value, represented by our names on the marriage certificate, which is the physical equivalent of a row in a Marriages table with columns Husband
and Wife, each referencing the primary key of a table People. 
This is a many-to-many relationship type (I've been married twice so would be in two rows, my first wife would also be in two rows as she remarried too). 
It is resolved into two one-to-many relationship types, People to Marriages in each case, in one case via the Husband column in the other via the Wife column.
In a relational database tables model Entity Types. 
In the above example People is an entity type, modelled by the People table. 
Marriage is also an entity type, modelled by the Marriages table. 
As we've seen it's also a relationship type.  In fact a relationship type is just a special kind of entity type.
Each column in a table represents an attribute type of each entity type, so attribute types of People might be FirstName,
LastName, DateOfBirth etc.  This table would also have a PersonID numeric column (usually an autonumber) as its primary key as names are not distinct. 
Each row in a table represents one instance of the entity type, and the attributes of each instance are represented by values at column positions in the row. 
This is the only way that data can be legitimately stored in a relational database.
It's important that there is no redundancy in the information content of the database. 
This is achieved by the process of 'normalization'.  Normalization is based on a set of 'normal form's ranging from First Normal Form (1NF) to Fifth Normal Form (5NF) and beyond, though the higher normal forms are of a rather 
different nature and we need not concern ourselves unduly with them. 
There is also a Boyce/Codd Normal Form (BCNF) which was inserted when it was found that the original Third Normal Form was deficient; it didn't cater satisfactorily for tables with two or more candidate keys where the keys were composite and overlapped,
i.e. Had a column in common.  I won't go into the details of normalization here; you'll find it written up in plenty of places.
To see an example of redundancy and therefore a table which is not properly normalized take a look at the Customers table
in the sample Northwind database which comes with Access.  You'll see that it includes City, State/Region and Country columns. 
If you look at its data you'll see for instance that we are redundantly told twice that Boston is in Massachusetts, and that this is in the USA 
twice.  This is not just inefficient, it is dangerous as it leaves the table open to inconsistent data being entered. 
There is nothing to stop somebody putting Boston in the Massachusetts in one row and Milwaukee 
in another, or putting Milwaukee  in the UK in one row and the USA in another. 
To normalize the table it should be decomposed into Customers, Cities, Regions and Countries tables, each of the first three with a foreign key referencing the primary key of the next table up in the hierarchy."
In your case you say a book can have more than one publisher. 
This is true if you regard the entity as the book as a single 'work', not as a title. 
I have two copies of Jane Austen's Mansfield Park for instance, each by a different publisher. 
It is a single 'work' however.  I've no idea if anyone else has written a book called Mansfield Park, but there is no reason why not, so let's assume that one exists.
 This is not the same 'work' as Jane Austen's book, so conceptually is a different entity of type Books, and would be represented by a separate row in a table Books.
In the above context there is a many-to-many relationship type between Books and Publishers. 
There is only one way to model such a relationship type, which is by a table which resolves the relationship type into two one-to-many relationship types. 
So the model would, diagrammatically be:
Books----<BookPublishers>----Publishers
Title is a non-key column of Books. 
The same title may appear in different rows, as with our hypothetical Mansfield Park by another author. 
The primary key of books is a numeric BookID, usually an autonumber. 
The BookPublishers table would have foreign keys BookID and PublisherID referencing the primary keys of the two referenced tables. 
It would also have columns representing any attributes of the relationship type between the book and the publisher. 
The primary key of this table is a composite one of BookID and Publisher.
To record multiple editions of a book published by a publisher requires another table along the following lines:
BookEditions
....PublisherID 
(FK)
....BookID 
(FK)
....EditionNumber
....EditionDate
.....ISBN
In this table PublisherID and BookID are a composite foreign key referencing the primary key of BookPublishers. 
Note that ISBN is a column in this table as it applies to each edition of a book. 
In the language of the relational model it is said to be functionally determined by the key of BookEditions.
Hopefully my short stock description of the relational model above, and my brief description of how it applies to the reality
which you are attempting to model will give you an insight into how to build a database, but I would strongly recommend that you first do some background work on how the database relational model works and how to apply its principles in Access.
I'll leave you with my own four, not altogether serious but nevertheless valid, ground rules for designing a relational database:
1. 
KISS (Keep it simple, stupid!).
2. 
When in a hole the first thing to do is stop digging.
3. 
Always take account of Murphy's Law: 'If something can go wrong, it will go wrong'
4. 
Always follow the advice given by Richard Feynman to his students: 'Don't write it down until you understand it'.
Ken Sheridan, Stafford, England