Search results

The idea of identifying customers by name and date of birth seems to me far too unrealistic to be worth considering. What kind of business would want to ask their customers for their date of birth? True there are cases where the date of birth might be required for customers, healthcare...

Be sure to make (EmployeeID, barwar) a key if appropriate. Uniqueness in general should be enforced through a unique constraint/index and not just in a form. There's no harm in adding an extra check into the form as well if you wish, but arguably it might be better to implement the composite key...

As I already stated more than once, my "fixation" is not on null sets vs. empty sets at all but on null vs. empty sets. In Access or in any SQL-based database they are not the same thing and don't mean the same thing. Since you keep returning to the different topic of null sets I don't see...

Are you really saying that you reject the Closed World Assumption - keystone of the relational model and SQL? Under the CWA, given the following query: SELECT age FROM employees WHERE empname = 'zsmith'; If the empty set is returned then that means there is no employee called 'zsmith'. If...

I think you are looking for something complicated in something that is very simple: CREATE TABLE t1 (x INT); INSERT INTO t1 VALUES (NULL); Now try the following two queries: SELECT * FROM Table1; SELECT * FROM Table1 WHERE 1=0; See the difference? The first SELECT query returns a null. The...

The actual question doesn't seem to have anything to do with the title of the thread. And 15000 rows is not really massive is it?

I have commented on this FAQ article by The_Doc_Man before. Unfortunately I just came across another reference to it and so I'm making a plea to reason here: please, please correct this article (or preferably delete it!) Here is an excerpt: This is so completely wrong. In relational and SQL...

It's very easy for anyone to find out where your back end database is. Exactly. You can have a secure database or you can have an Access database, but they are mutually exclusive. That's why adding point-to-point encryption and password security does more harm than good in my opinion - unless...

Like this: CREATE TABLE t1 (x AUTOINCREMENT PRIMARY KEY, z String NOT NULL);

In different ways both of the two choices you mention are slightly unusual and probably not the options you should prefer. MySQL has lost its popularity since Oracle purchased it and many people prefer MariaDB (a MySQL offshoot) nowadays. Access has no merits at all for any new-build web...

:eek: I can promise you most do not. SQL Server Management Studio is by far the best tool for developing SQL Server queries. It has loads of useful features that you can't get in the Access query designer: a full object browser, intellisense, actual and estimated query plans, query batches -...

Note that many NHS hospitals (and healthcare organisations worldwide) do use rostering systems and there is some evidence that they have helped reduce costs. http://www.nhsemployers.org/your-workforce/plan/agency-workers/reducing-agency-spend/e-rostering (Disclosure: I have worked as a paid...

Probably because someone is inserting a value or values into the autonumber column. Whenever any person or process does that the next generated value for the table "jumps" to the number after the value inserted. The same jump happens for everyone, not just the person who inserted the value(s).

Access is an application development tool but it also includes a database engine called Jet/ACE which stores data in MDB / ACCDB files. Jet/ACE would not be a wise choice for the kind of situation you describe. A SQL DBMS (such as SQL Server, Oracle, MariaDB for example) with a client-server...

Doc Man, I don't think you read or understood me. Like you I am concerned with simplicity and performance. Adding an unnecessary extra key is likely to increase complexity (because more joins may be needed in queries where none were needed before) and in many cases will hurt performance (queries...

Don't make your decisions about keys based on size - that's just folly! I think we are talking about a Jet/ACE database here which means by definition that the sizes involved are tiny and the storage costs utterly trivial. If your database is larger than 1GB then you should be considering moving...

That's OK by me. You asked what the problem was and I answered. Maybe this discussion will help someone.

Of course suppliers issue unique invoice numbers, but people still sometimes make mistakes when keying them into computer systems. The point of enforcing uniqueness is to help ensure data integrity by preventing the database from getting in an incorrect state in the first place. Every accounting...

I am extremely familiar with reading, and designing, database schemas. Exactly, and that's why it makes sense to have a uniqueness constraint on the composite of Supplier and Invoice Number, i.e. a composite key. Failing to do that would mean the database design would not be an accurate...

Without a uniqueness constraint on (Supplier, InvoiceNumber) your suggested schema would allow duplicate data and it would no longer be possible to identify invoices uniquely for each supplier. Maybe an invoice would get paid twice as a result (it happens more often than you think). That's why...