Search results

Row numbering is an extremely common thing to do and it's perhaps surprising that people here seem to be questioning such a requirement. Numbering is something that's supported by every major DBMS, typically using the standard SQL RANK() / ROW_NUMBER() functions. Unfortunately Access doesn't...

Definitely neither of those. I'd suggest you purchase an off-the-shelf CRM / accounting solution. There are plenty that should cover your requirements and you can pretty much guarantee they will work out much cheaper than any reasonable attempt to develop it yourself or outsource it.

No reason to show numeric keys? Well that certainly depends on the key and on whether there are alternative keys available for the user. For example if the numeric key is an invoice number then presumably that is the principal method used by the business and by customers to identify invoices...

MySQL does support Referential Integrity using the InnoDB storage engine (which is the default storage engine for new installations). FuzMic, to the extent that there is a real difference of opinion here, the difference rests largely on different understandings of the purpose of keys and...

You might instead like to read these comments on those very same videos, and then perhaps take a look at some alternative learning resources. http://www.access-programmers.co.uk/forums/showpost.php?p=1419465&postcount=11 http://www.access-programmers.co.uk/forums/showpost.php?p=1419474&postcount=12

Jdraw, The content of these videos is really extremely poor. I mean just plain wrong and thoroughly misleading to students and beginners. I know I have said the same before and I guess you disagree because you must have posted links to them a few times. The trouble is they are so bad that I...

It's not generally good practice to store passwords, either plain or encrypted. Best practice is usually to store a secure hash of the password so that it's not possible to recover the password by snooping in the database. You can do that quite simply in SQL Server by using the HASHBYTES function.

If you want the instances where the same id has two different names, try this: SELECT id FROM YourTable GROUP BY id HAVING MIN(Name)<MAX(Name);

If Access 2010 is an option then you can use Microsoft's native source control support. Microsoft removed source control from Access 2013 - presumably in line with their positioning of Access as an power user tool rather than a developer tool...

Like this? CREATE TABLE CarrierDeparturePossible (CarrierCode VARCHAR(4) NOT NULL, CountryCode VARCHAR(3) NOT NULL, PRIMARY KEY (CarrierCode, CountryCode));

Yes, that's what Spike is saying. If you insert a value to an autonumber column by using an INSERT query then the numbering will restart from that number: INSERT INTO Table1 (id) VALUES (2000); where 2000 is the value from which you want the autonumber column to restart. If you have...

Doing joins over the network sucks I agree. But in the 21st Century there's no very good reason to use a file-based database on a network anyway. And even less reason to let legacy tech get in the way of sensible database design.

Which is why I said that what really matters is to validate that with the person who owns or is responsible for the data. Demonstrate to that person the actual steps needed to circumvent whatever method you use to "hide" the data. If he/she is happy to live with that then go right ahead. I could...

You cannot stop people copying and using the data in an ACCDB file if they have read permissions on that file via the file system. It's imporant that the owner of the data realises that and agrees that it's an acceptable risk. If that's not acceptable then you need to use a different solution...

There's nothing necessarily wrong with using an autonumber/IDENTITY to generate a "natural" key value for your business data. It's technically a superior method to taking the max + 1 of a column because it doesn't cause the same blocking/serialization problems. There are potential limitations...

Fortunately there is a much easier alternative. Just run the following query: ALTER TABLE Table1 ALTER COLUMN id AUTOINCREMENT (16224,1);

So let's take the example of a very simple query on a table with three attributes where (b,c) just happens to be a composite foreign key: SELECT a,b,c FROM tbl1; If you insist on referencing a surrogate instead then to get the same result I have to do a join: SELECT tbl1.a, tbl2.b, tbl2.c...

Welcome Fred, This looks like homework to me. The best way to tackle such an exercise is to write down the dependencies as you would understand them to be and then validate your potential database designs against those dependencies. For example, I could guess that AnswerID->QuestionID (meaning...

Just to be clear on the terminology: that is not two keys, it's one key consisting of two attributes AKA a composite key. I suggest you avoid the term compound key because in some contexts that means something different. Two keys would mean two attributes (or more generally two sets of...

However, if you replace every composite foreign key in a database with a synthetic single attribute then you will be forced to do a join every time you need to retrieve the meaningful key values that really matter. If you use composite keys you may not need to do a join at all or you will need...