Search results

Yes of course. Users initiate searches and they will presumably want to search on a variety of things and not just the key attributes. Users will not generally need to search for things based on a surrogate key, so if the surrogate key is used to support users' queries at all then it requires an...

I never use the Designer and I don't know anyone who does. The SQL Server Designer window is not nearly as bad as its equivalent in Access but it's still more trouble than it's worth IMO. An easy way to edit a view definition is to right-click the view in the Object Browser in Management...

With a Natural Key of course. I asked the question only because you seemed to be implying that there was no need to bother with natural keys because one could always use a surrogate instead. Natural keys are essential in good database design. They are no less essential just because you use...

tehNellie, Well said. I agree with what you have said. For the reasons you have given I agree that the choice of "primary" key is essentially irrelevant and uninteresting. What really matter are the natural keys and how they are used. I.e. how is information in the database uniquely...

So how do you expect your end users to identify the information in such a table? Your auto-number key won't help them uniquely identify anything because you've already told us you intend to hide it from them. Yet you don't appear to be suggesting any alternative. That's why I'm saying your point...

I hope not. The idea that the law should tell me what indexes I can create seems extraordinary. I can't see why that would be any concern of privacy laws. I think the legitimate concern being expressed (perhaps in a flawed way) by legislators is really about the risks to individuals due to...

That's what I'd hoped. Your superiors applied common sense and they seem to agree with what I said before: A privacy violation is caused by misusing, storing or needlessly exposing the SSN. It has nothing to do with whether it happens to be a primary key - the privacy violation is the same...

The topic here is natural keys, i.e. the real world identifiers to be used for things in a database table. Adding a surrogate to a table doesn't eliminate the need for a natural key in that table. A surrogate doesn't solve any problems around the "misuse" of natural keys. Useful as they may be...

You mean you must remove the SSN altogether? That's a step forward in terms of privacy I agree. Would it have made a difference if you left the SSN in the table but it was not a key? (i.e. you allowed duplicates). For my benefit, please explain in what way it is a violation of privacy to make a...

Stang, I think your instinct is right. I would expect to create a table for duties, with columns for EmployeeId, Duty, HoursWorked, Overtime. That table would have one row per employee/duty. Normalization doesn't mean you have to eliminate information that is "duplicated". What it means is...

If you don't want users to delete some piece of data then you have to deny them permission to delete that data. You clearly can't stop users from writing SQL but that doesn't mean you should give them the opportunity to do harmful things with it.

If your data is an Access database (meaning Jet/Ace) then you cannot secure it from users who have read or write access to that database file. So if security is any part of your requirement then you need to move your database to another platform. Assuming you do that, I think your concerns...

Re: To split or not? / how to make improvements during use My opinion: The idea of putting data and application into a single file is just barmy. For the reasons you have stated, among many others, it is illogical, pointless and highly inconvenient for everyone. Hope that answers the question :)

Re: Primary key values and control characters The design of keys should be driven by business requirements. If you wanted a purely machine-readable key then it might be an option to use arbitrary binary data, including special characters. If human beings are expected to read and enter key...

I suggest you might emphasise the usefulness of Access as a RAD development tool that can integrate with corporate system software e.g. being a lightweight, agile choice of front-end to SQL Server / Oracle. I think that's a more valid corp-friendly use case than the idea of Jet as a "shadow"...

I'd assume for such a significant change you would do the upgrade well in advance of go-live, run a series of tests and have a period of parallel running to make sure all was going well. If you didn't do that then I'd seriously rethink what you are attempting here. Downgrade to how it was before...

SSRS means SQL Server Reporting Services, which is the reporting component of Microsoft SQL Server. It isn't difficult to master the basics of SSRS, so as Rain suggests you could install it and start to teach yourself or learn from a book. If you've used other reporting tools then you shouldn't...

I wouldn't say that. There are plenty of situations which are accurately modelled by loops in an ER diagram. When you see a loop in an ER model (especially if it appears to be a circular dependency) it's certainly worth taking a second look, but the presence of loops doesn't automatically mean...

Whenever you encounter two tables with the same structure and meaning that is usually considered a reg flag - not necessarily completely unjustified in every case but at least worth a careful second look to see if your design really makes sense. The reason it's considered a questionable design...

There are a few things to look out for. For example, features that depend on row order may not work the same way; uniqueness constraints and foreign key constraints behave differently with null values; cascading referential integrity is different. If you are using bound forms then consider...