How to normalize contacts in Access

You're talking to a lot of people who've been around the block and used other environments. Why are we now using Access? Because despite its age (and ours as well), it is a pretty robust tool for certain types of projects. If you want to develop a web app, you're in the wrong forum. If you want to develop a project that is going to require a dozen programmers banging away at the same time, you're in the wrong forum. If you want to develop a project that will run on a phone, you'll be very unhappy with Access.

If you want to tell us in a paragraph or two what you are trying to develop and the environment you need it to run in, we can tell you if you should proceed with Access or find a different tool.
 
Suggestions HAVE been made to which you responded with "back in my day-esque" responses. Rather than try to defend your position, why not try the suggestions of those you solicited?
What makes you think I haven't tried lots of suggestions the past few weeks? Do you have a spy camera in my office? Of course, I can't try all of the suggestions, as some don't fit my situation. As I said earlier, I tried to post what I know works from past experience, despite the assurance from George that it's impossible. Sorry you don't like that.
 
You're talking to a lot of people who've been around the block and used other environments. Why are we now using Access? Because despite its age (and ours as well), it is a pretty robust tool for certain types of projects. If you want to develop a web app, you're in the wrong forum. If you want to develop a project that is going to require a dozen programmers banging away at the same time, you're in the wrong forum. If you want to develop a project that will run on a phone, you'll be very unhappy with Access.

If you want to tell us in a paragraph or two what you are trying to develop and the environment you need it to run in, we can tell you if you should proceed with Access or find a different tool.
Sorry, my original post was 9 paragraphs, several of those just one liners though. I don't think the question was about any of the things you listed. They weren't my topic.
 
Then I wish you the best of luck in your Access journey
 
Over the years, I've come to the realization that a tactic often employed to conceal one's lack of understanding of a basic concept is a relentless outpouring of bafflegab meant to distract and deflect from the point at hand.

...

As Pat pointed out in one of her responses (post #45), there is virtually no limit--at least in theory--to the number of data sources one can consume from Access. What one CANNOT do, though, is bypass the very real constraints of the individual databases involved--Referential Integrity being the relevant one here (emphasis added).

By the way, look up the Sleep API and how you can use it "...in VBA to pause for a given number of seconds". You are technically correct, it's not a native VBA command. But a VBA programmer would know about APIs and how to use them to augment what isn't native. There is a point to mentioning this, beyond merely addressing this complaint.

It is that a good developer learns what the limitations of the various tools are, and instead of going on and on about how awful the tools are, sets about trying to find solutions.

I encourage you to move on and take up the task of learning the tools available to you in Access and start addressing the questions David raised for you.
As I said, I was just answering a question that another forum member asked. Sorry that bothered you. But since you've been in data processing and around computers for far longer than me, none of what I wrote should be a gray wall to you, as I saw the same ideas implemented by dozens of developers of enterprise solutions (I listed the companies using those solutions, but maybe you never worked for any of them?). But maybe you ran with a different pack in your dp days?

I think that referential integrity had nothing to do with my original post.

Gee, as I've reacquainted myself with Access over the last two months, I wonder what I was doing all that time if not "take up the task of learning the tools available to you in Access." But hey, I may have suffered some brain damage as I banged my head against the wall with a plethora of Access bugs. I posted two or three links to my research on some of those earlier. And my solutions in a few cases on other threads for those who think I've only asked complaining questions.
 
Last edited:
I did notice one thing that I have to agree was right. See post #44 of this thread.

You mentioned using multiple back-ends for Access and then listed the idea that some FTC rules and some banking rules required it. Regulatory isolation is one of the rare situations that would cause you to split back-ends even though they might otherwise have actually fit together. Having worked with the U.S. Navy for a while in the hierarchy NAVY>>(NAVPERS&NAVMED)>>(BUPERS&BUMED), I understand about regulator separation.

Having agreed that was right, I do not wish to imply any kind of aspersions about some of the other things you said. Except this one:

"Only later did the idiots at Microsoft think it was a good idea to mix data with programming in one place." Yes, they did - but they also included a way to split them once you got the basics working again. So, yeah, maybe not theoretically ideal - but very practical for projects just starting to get up off the ground, and not really that difficult to split things apart when needed. Therefore, I can't get worked up about that fact.

What is more important is something else that you alluded to - that M$ never saw a good idea they couldn't steal borrow. When Windows NT came out, its kernel was hugely adapted to match the OpenVMS kernel, which makes sense because Dave Cutler wrote both of them. Part (not all) of my understanding of Windows internals is because after NT, they closely parallel OpenVMS internals.
 
"Only later did the idiots at Microsoft think it was a good idea to mix data with programming in one place." Yes, they did - but they also included a way to split them once you got the basics working again. So, yeah, maybe not theoretically ideal - but very practical for projects just starting to get up off the ground, and not really that difficult to split things apart when needed. Therefore, I can't get worked up about that fact.
I get a lot of security patches from M$ (I like that) for Office that says M$ still hasn't figured out to do what you suggest.
Not to mention the warning that comes up from almost every new database I open from someone else.
 
I get a lot of security patches from M$ (I like that) for Office that says M$ still hasn't figured out to do what you suggest.

What? The "split data from programming part?" The database splitter does the FE/BE split just fine, and where dealing with native Access BE files, the FE can be on a physically different machine. So that's a split. ACE is capable of responding to ODBC connectivity, so your programming can be elsewhere. That's another type of split. It is true that ACE was not designed for huge, hulking installations. But how much of a data/programming split do you want? Telepathy? I'd hate for that to be possible because of all the swear words it would remember.
 

Users who are viewing this thread

Back
Top Bottom