Search results

Hopefully they won't kill you they way they did my father. He spent six months gasping for air due to his inoperable lung cancer, then one night drowned in his own blood. I've had two grandparents die of lung cancer as well, both, like my father, life-long smokers. Possibly three, but I was...

OR in JOIN clauses are perfectly valid, although it's far more common to see in a WHERE clause. It's most commonly done when you want to restrict the records being pulled in to the temporary table being created behind the scenes, as opposed to after the table is created. In theory, OR in the...

If you look closely, it also gives an example of aliasing. That's something you don't usually have to deal with in Access, since most queries are handled through the QBE grid, but if you ever start working with SQL Server, it's a godsend.

You know, that is an amazing graphic to have when explaining joins. I'm totally ganking that thing.

Bah, jdraw beat me to part of it while I was typing that beast up. :(

Not really sure where your confusion is. If you create an actual relationship between two tables (on the ribbon: Database Tools -> Relationships, then drag the parent field (tblParts.PartID, for example) to the child/many table over the field you want to link it to (tblAssemblyItems.PartID)...

Bah, should have been 'acquire', not 'require'. Fixing the original quote.

In English, it pulls in the ID's for all parts that are in tblAssemblyItems that are not in tblParts. I believe it's one you can find in the query wizard as a 'find unmatched query'. And it perfectly shows the reason why relationships are so important. Had the relationship been set up before...

As an example, a couple years back, another poster requested help designing a database where he had to track clients, documents, and which documents were on file for each client. The solution was much the same: a clients table, a documents table, and a documents log (the junction table). I...

Sure you can. One-to-Many joins do not require every entry in the One side to exist in the Many side. In your case, it's perfectly acceptable to have parts in your Part table that do not appear in your junction (Assembly Items) table. The inverse, however, is not true: as the Many side of the...

Same with my insurance company. We even just use Windows Authentication rather than specific server logins. And application whitelists....

They do say that experience is knowledge you acquire immediately after you actually needed it.

SHHHHHH You're weakening my point! ;) And I actually kind of covered that with my reply directly before the one you quoted.

Also, if they say it's for a smaller company... The Doc Man spent a career as a Department of Defense programmer, and used Access all the time. Isladogs owns a software development company whose primary offerings are Access databases that are used to run school districts. I work for one of...

The basics aren't too hard, but a full SQL Server install requires them to keep a DBA on-hand to handle the maintenance. A smaller solution is available with SQL Server Express, which is free but limited to 10 Gb databases. You can learn the basics of using SQL server fairly easily by jumping...

No, we use a SQL Server back end. We have tables that are in the terabyte size range, and Access files corrupt and die once you pass 2 Gb. Also, security is a joke with Access backends, so if you need to keep your data secure, you NEED to go with other solutions for the database itself. Your...

It will have to wait until after work to look at the database - I just have a couple minutes while a query runs. For a junction table, you have a compound primary key that is comprised of foreign keys to matching primaries on different tables. As an example, a 'ProductComponents' table would...

Is it actually important to identify 'top' and 'bottom' in your product data? How do you currently store the data for products with any number of components other than 2, or with an assembly that's something other than top and bottom? If Top and Bottom have to be tracked, then use them as...

That would be why I stopped binding directly to tables for anything other than data entry once I started working here. Having to put a sort order on a 1.6 billion record table with 150 fields (1.8 billion now) made form loading a bit slow.

As corroboration of Colin's point, I regularly work with VERY large tables. I'm talking nearly 2 billion records and over a TB in table size. Certain searches would take 20 to 30 minutes before indexing, and 2-3 seconds after indexing. That's an extreme example, but it shows the worth of...