By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,474 Members | 1,001 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,474 IT Pros & Developers. It's quick & easy.

Deploying new app. Upgrade theory

P: n/a
ARC
Hello again,

I'm close to the end of converting a large app from access 97 to 2007.

I have many users on the old system, with the db's in Access 97, and here's
what I'm thinking of doing to convert the older folks db's. I've changed
tables around a bit, added new tables, and deleted un-used fields, otherwise
I would do a convert. I'm going to write a routine that will do the
following:

1) Upon launching the app, if I detect that the database is blank, I'll open
a dialog asking if they want to begin a new database, or import from an
existing db.

2) If they choose existing, I'll ask them to browse to their database files
that were in Access 97. (This is a parts, customers, quoting/invoicing
program, so maybe I'll give them an additional option to just import parts
and customers if they want to start with a cleaner db)

3) One table at a time, I'll import the data, from the Acc 97 db's to the
blank acc 2007 db's, using sql and runquery commands. At the moment, I'm not
sure how hard this will be, or whether I would need to temporarily link to
the old tables or use the transferdatabase commands.

4) I'll then do the same for the handful of additional local .mdb's, where
I'll import the data into fresh/blank access 2007 databases.

Does this seem like a sound approach? Any pitfalls, or better alternate
solutions?

Many Thanks,

Andy
Aug 20 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On Mon, 20 Aug 2007 14:08:39 GMT, "ARC" <an**@andyc.comwrote:

I'm not getting it.
Upgrading typically involves upgrading/creating a new front-end (FE)
by the developer only. The back-end (BE) stays on the server. All
users get the new FE, and you're done.

Now you may well want to upgrade your BE as well. So kick all users
out of the app for an hour, upgrade the BE manually, distribute the FE
to everyone, have them launch it, it connects to the upgraded BE, and
you're done.

Tony Toews has a auto-updater utility on his site.

-Tom.
>Hello again,

I'm close to the end of converting a large app from access 97 to 2007.

I have many users on the old system, with the db's in Access 97, and here's
what I'm thinking of doing to convert the older folks db's. I've changed
tables around a bit, added new tables, and deleted un-used fields, otherwise
I would do a convert. I'm going to write a routine that will do the
following:

1) Upon launching the app, if I detect that the database is blank, I'll open
a dialog asking if they want to begin a new database, or import from an
existing db.

2) If they choose existing, I'll ask them to browse to their database files
that were in Access 97. (This is a parts, customers, quoting/invoicing
program, so maybe I'll give them an additional option to just import parts
and customers if they want to start with a cleaner db)

3) One table at a time, I'll import the data, from the Acc 97 db's to the
blank acc 2007 db's, using sql and runquery commands. At the moment, I'm not
sure how hard this will be, or whether I would need to temporarily link to
the old tables or use the transferdatabase commands.

4) I'll then do the same for the handful of additional local .mdb's, where
I'll import the data into fresh/blank access 2007 databases.

Does this seem like a sound approach? Any pitfalls, or better alternate
solutions?

Many Thanks,

Andy
Aug 21 '07 #2

P: n/a
On Mon, 20 Aug 2007 14:08:39 GMT, "ARC" <an**@andyc.comwrote:

I'm not getting it.
Upgrading typically involves upgrading/creating a new front-end (FE)
by the developer only. The back-end (BE) stays on the server. All
users get the new FE, and you're done.

Now you may well want to upgrade your BE as well. So kick all users
out of the app for an hour, upgrade the BE manually, distribute the FE
to everyone, have them launch it, it connects to the upgraded BE, and
you're done.

Tony Toews has a auto-updater utility on his site.

-Tom.
>Hello again,

I'm close to the end of converting a large app from access 97 to 2007.

I have many users on the old system, with the db's in Access 97, and here's
what I'm thinking of doing to convert the older folks db's. I've changed
tables around a bit, added new tables, and deleted un-used fields, otherwise
I would do a convert. I'm going to write a routine that will do the
following:

1) Upon launching the app, if I detect that the database is blank, I'll open
a dialog asking if they want to begin a new database, or import from an
existing db.

2) If they choose existing, I'll ask them to browse to their database files
that were in Access 97. (This is a parts, customers, quoting/invoicing
program, so maybe I'll give them an additional option to just import parts
and customers if they want to start with a cleaner db)

3) One table at a time, I'll import the data, from the Acc 97 db's to the
blank acc 2007 db's, using sql and runquery commands. At the moment, I'm not
sure how hard this will be, or whether I would need to temporarily link to
the old tables or use the transferdatabase commands.

4) I'll then do the same for the handful of additional local .mdb's, where
I'll import the data into fresh/blank access 2007 databases.

Does this seem like a sound approach? Any pitfalls, or better alternate
solutions?

Many Thanks,

Andy
Aug 21 '07 #3

P: n/a
ARC
I wish it were that easy. I should have spelled out from the start that the
user's are not local. Instant Quote Pro is the software in question, and the
user's are in many different countries and locations.

From day 1, my front / back end has been in Access 97, so now both are in
2007 on my development machine. I can't see having the FE as acc 2007, and
leaving the BE in 97, as it seems that could lead to problems. Also there's
pressure over the years from my customer base to upgrade the BE data to a
newer version.

Andy
"Tom van Stiphout" <no*************@cox.netwrote in message
news:7i********************************@4ax.com...
On Mon, 20 Aug 2007 14:08:39 GMT, "ARC" <an**@andyc.comwrote:

I'm not getting it.
Upgrading typically involves upgrading/creating a new front-end (FE)
by the developer only. The back-end (BE) stays on the server. All
users get the new FE, and you're done.

Now you may well want to upgrade your BE as well. So kick all users
out of the app for an hour, upgrade the BE manually, distribute the FE
to everyone, have them launch it, it connects to the upgraded BE, and
you're done.

Tony Toews has a auto-updater utility on his site.

-Tom.
>>Hello again,

I'm close to the end of converting a large app from access 97 to 2007.

I have many users on the old system, with the db's in Access 97, and
here's
what I'm thinking of doing to convert the older folks db's. I've changed
tables around a bit, added new tables, and deleted un-used fields,
otherwise
I would do a convert. I'm going to write a routine that will do the
following:

1) Upon launching the app, if I detect that the database is blank, I'll
open
a dialog asking if they want to begin a new database, or import from an
existing db.

2) If they choose existing, I'll ask them to browse to their database
files
that were in Access 97. (This is a parts, customers, quoting/invoicing
program, so maybe I'll give them an additional option to just import parts
and customers if they want to start with a cleaner db)

3) One table at a time, I'll import the data, from the Acc 97 db's to the
blank acc 2007 db's, using sql and runquery commands. At the moment, I'm
not
sure how hard this will be, or whether I would need to temporarily link to
the old tables or use the transferdatabase commands.

4) I'll then do the same for the handful of additional local .mdb's, where
I'll import the data into fresh/blank access 2007 databases.

Does this seem like a sound approach? Any pitfalls, or better alternate
solutions?

Many Thanks,

Andy

Aug 21 '07 #4

P: n/a

"ARC" <an**@andyc.comwrote
>I wish it were that easy. I should have spelled out from the start that
the
user's are not local. Instant Quote Pro is the software in question, and
the
user's are in many different countries and locations.

From day 1, my front / back end has been in Access 97, so now both are in
2007 on my development machine. I can't see having the FE as acc 2007,
and
leaving the BE in 97, as it seems that could lead to problems. Also
there's
pressure over the years from my customer base to upgrade the BE data to a
newer version.
Is there a compelling reason to convert to Access 2007 even before SP1 is
available? There are quite a number of known "issues". If I were
distributing an application to remote users, and could not defer until I saw
how stable Access 2007 SP1 turns out to be, I'd do an interim update to
Access 2003.

Larry Linson
Microsoft Access MVP
Aug 21 '07 #5

P: n/a
ARC
I guess the only compelling reason is a promised time constraint (customer's
are expecting a new major version, in a newer version of Access by
September, and a number even offered to pay in advance), and already being
95% complete with the 2007 version. I never did purchase the 2003 version of
Access. From what I've seen in my testing, and what I've read myself, is
that Access 2007, with all it's major changes, is surprisingly stable.
That's what I have to hope anyway.
"Larry Linson" <bo*****@localhost.notwrote in message
news:OrGyi.1297$Uf7.303@trnddc06...
>
"ARC" <an**@andyc.comwrote
I wish it were that easy. I should have spelled out from the start that
the
user's are not local. Instant Quote Pro is the software in question, and
the
user's are in many different countries and locations.

From day 1, my front / back end has been in Access 97, so now both are
in
2007 on my development machine. I can't see having the FE as acc 2007,
and
leaving the BE in 97, as it seems that could lead to problems. Also
there's
pressure over the years from my customer base to upgrade the BE data to
a
newer version.

Is there a compelling reason to convert to Access 2007 even before SP1 is
available? There are quite a number of known "issues". If I were
distributing an application to remote users, and could not defer until I
saw how stable Access 2007 SP1 turns out to be, I'd do an interim update
to Access 2003.

Larry Linson
Microsoft Access MVP

Aug 21 '07 #6

P: n/a
"ARC" <an**@andyc.comwrote in
news:ZZ*****************@newssvr22.news.prodigy.ne t:
P.S. I guess the reason I steered clear of relationships was I
found the Access 97 relationships window to be buggy. You'd close
the window, re-open, and tables would start multiplying! Before
you knew it, there would be hundreds of tables in there, so my
boss at the time made a decision to do away with using them, and
we handled all RE ourselves (which we did quite well with thinking
through all the possibilities). I guess a programmer's style is
definetely formed from early jobs. I did read, however, about bugs
with Acc 97 relationships, especially something about importing
objects and always un-checking relationships.
That's the most preposterous thing I've ever heard.

I've never experieinced any problems with the relationships window
approaching your description. But, one definitely does have to stay
on top of keeping it organized in a useful layout. Selectively
hiding and revealing parts of the structure is also necessary with
large numbers of tables.

But just abandoning RI because of that? That's so idiotic it
astonishes me. RI is the most basic part of any relationship
database. Without it, all you've got is *data*, not a *database*.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 21 '07 #7

P: n/a
Tom van Stiphout <no*************@cox.netwrote in
news:14********************************@4ax.com:
I too am having fun with ribbons, but I'm also often asking the
why question, such as why is there no Controls collection in a
Ribbon object. I'm still hoping to find an article discussing the
design philosophy, which seems so different from other parts of
the tool. Another example is where I wanted to fill a dropdown
with values from the db. If we had to write the same kind of code
for a regular dropdown, Access wouldn't be the successful tool it
actually is.
Are the ribbons not stored in XML? If that's so, then there ought to
be a DOM object model, as in web pages. I don't know if that's been
exposed somewhere, but it might give you a collection-based approach
to manipulating the ribbons if it is.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 21 '07 #8

P: n/a
ARC
Ok, let's get back to constructive help here...I'll admit I'm a newbie at
letting the computer handle RE, it's just the way I was mentored, and the
direction the company I worked for chose to go.

What I really need help with is when to use the cascade updates and deletes.
I'm still trying to understand this. If you have a shipping type on an
invoice, and someone wants to delete the shipping type, obviously I want to
prevent this, and not use the cascade deletes. Same would go for a payments
table, and the payment typeID, if they try to delete the payment type, you'd
want to prevent it.

Now in the case of a QuotesHdr and QuotesDetail table, if they delete the
quoteHdr entry, naturally I'd want to delete all quotedetail entries as
well, and use the cascade delete.

Any tips you can give on using the cascade options?

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"ARC" <an**@andyc.comwrote in
news:ZZ*****************@newssvr22.news.prodigy.ne t:
>P.S. I guess the reason I steered clear of relationships was I
found the Access 97 relationships window to be buggy. You'd close
the window, re-open, and tables would start multiplying! Before
you knew it, there would be hundreds of tables in there, so my
boss at the time made a decision to do away with using them, and
we handled all RE ourselves (which we did quite well with thinking
through all the possibilities). I guess a programmer's style is
definetely formed from early jobs. I did read, however, about bugs
with Acc 97 relationships, especially something about importing
objects and always un-checking relationships.

That's the most preposterous thing I've ever heard.

I've never experieinced any problems with the relationships window
approaching your description. But, one definitely does have to stay
on top of keeping it organized in a useful layout. Selectively
hiding and revealing parts of the structure is also necessary with
large numbers of tables.

But just abandoning RI because of that? That's so idiotic it
astonishes me. RI is the most basic part of any relationship
database. Without it, all you've got is *data*, not a *database*.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Aug 21 '07 #9

P: n/a

"ARC" <an**@andyc.comwrote
From what I've seen in my testing, and what
I've read myself, is that Access 2007, with all
it's major changes, is surprisingly stable.
That's what I have to hope anyway.
Good luck.

Larry Linson
Microsoft Access MVP
Aug 21 '07 #10

P: n/a
"ARC" <an**@andyc.comwrote
Ok, let's get back to constructive help here...
I'll admit I'm a newbie at letting the computer
handle RE, it's just the way I was mentored, and the
direction the company I worked for chose to go.
I, too, am at a loss to either understand, or explain, the phenomenon you
describe. I've never seen anything remotely resembling it, nor, in fact,
ever heard of it -- and I've been using Access daily since Jan. 1993, in all
versions. Did this happen to you, personally, or are you relating the
"reason" you were given for your company's "direction"?
What I really need help with is when to use the cascade updates and
deletes.
. . .
Now in the case of a QuotesHdr and QuotesDetail table, if they delete the
quoteHdr entry, naturally I'd want to delete all quotedetail entries as
well, and use the cascade delete.
This is what Cascade Update and Cascade Deletes are meant for. In many
applications, however, we keep Records as History (right in the same table,
marked in some way as "archive" or "inactive") and in that case, Cascade
Update and Cascade Delete aren't useful. They only apply if you change the
Key Field or delete the master (one-side) Record... in which case the
Related Records using that as a Foreign Key will also be changed or deleted.

If you are marking as "inactive", you may need do nothing to the related
records, depending on the structure of your application... if you have to
display the master record (as is [often|usually] the case) to view the
related records.

If you are moving the inactive records to an Archive or History Table, then
you'll have code to do so. In this case, you might make effective use of
Cascade Delete -- after moving all the records, when your code deletes the
master record, the related records will be deleted from the original tables.
Of course, in that case, you never give the user the ability to manually
delete a master record.

And, very many Access developers use an Autonumber as their Primary Key,
which will never be changed (you can't, at least without jumping through
roaring, flaming hoops). If you do, then Cascade Update won't be useful
either. Note that there are two sides to the "natural key versus surrogate
key" issue and I'm not going to start or participate in Yet Another
Subthread on that issue.

Referential Integrity is, however, extremely useful even without either of
these options. It prevents entry of an erroneously keyed related record and
inadvertent deletion of a master record which has related records prior to
the related records being first deleted.

Relationships, even without Referential Integrity, can be convenient (though
minimally so) as the related fields are joined when you include the related
tables in a Query. You still have to set the Join type if it is anything
other than an "Inner Join" (only records where the field is equal in both
tables). And, I have been told, but never could determine from real-world
use, that there are performance improvements over just Joining on the two
fields in a Query.

Larry Linson
Microsoft Access MVP

Aug 21 '07 #11

P: n/a
ARC
I really saw the bug. As an example, we had a very large reservation system,
and in the example of the Guests table, in the relationships window, I
didn't just see Guest_1, Guests_2, Guests_3, it went much much farther. The
screen was literally full of Guest_ iterations. And it seemed to multiply
each time we opened relationships. So my boss made the call to remove all
relationships and I had never used them since. And I do remember reading
about a bug, mainly with importing relationships, and I wish I could give
you the source, but I can't, it's been years since I remember reading about
it. I wish I could back this up, but I can't.

And thanks for your time to write the reply. I think from the sounds of it,
I should just use the enforce referential integrity, and not check the
cascade updates or deletes, that could, in fact, be dangerous. And thanks
for going easy on me! I was almost sorry I posted, as some replies weren't
so kind. I guess I just never used RE, and my program actually had a minimum
of orphaned data, and not the type that were show-stoppers. In my mind, I
always went though things logically. It's like, ok the user wants to delete
a quote. Confirm the delete first, then delete the quote header record, ALL
quote detail records, and so-on. The user wants to delete a customer. Ok,
check for customer invoices, quotes, payments, if they exist, prevent
deletion. I never found manual RE (if there' such a thing) to be that time
consuming, but now I can see the benefits of letting Access do it. I do need
to see how it does it, however, and make sure Access's messages to the user
make sense to them. Then I'll have to go through all my code and see if I
still need the manual RE coding. Yikes!

Thanks again, Larry.

Andy
"Larry Linson" <bo*****@localhost.notwrote in message
news:gSKyi.3749$iA.592@trnddc05...
"ARC" <an**@andyc.comwrote
Ok, let's get back to constructive help here...
I'll admit I'm a newbie at letting the computer
handle RE, it's just the way I was mentored, and the
direction the company I worked for chose to go.

I, too, am at a loss to either understand, or explain, the phenomenon you
describe. I've never seen anything remotely resembling it, nor, in fact,
ever heard of it -- and I've been using Access daily since Jan. 1993, in
all versions. Did this happen to you, personally, or are you relating the
"reason" you were given for your company's "direction"?
What I really need help with is when to use the cascade updates and
deletes.
. . .
Now in the case of a QuotesHdr and QuotesDetail table, if they delete
the
quoteHdr entry, naturally I'd want to delete all quotedetail entries as
well, and use the cascade delete.

This is what Cascade Update and Cascade Deletes are meant for. In many
applications, however, we keep Records as History (right in the same
table, marked in some way as "archive" or "inactive") and in that case,
Cascade Update and Cascade Delete aren't useful. They only apply if you
change the Key Field or delete the master (one-side) Record... in which
case the Related Records using that as a Foreign Key will also be changed
or deleted.

If you are marking as "inactive", you may need do nothing to the related
records, depending on the structure of your application... if you have to
display the master record (as is [often|usually] the case) to view the
related records.

If you are moving the inactive records to an Archive or History Table,
then you'll have code to do so. In this case, you might make effective
use of Cascade Delete -- after moving all the records, when your code
deletes the master record, the related records will be deleted from the
original tables. Of course, in that case, you never give the user the
ability to manually delete a master record.

And, very many Access developers use an Autonumber as their Primary Key,
which will never be changed (you can't, at least without jumping through
roaring, flaming hoops). If you do, then Cascade Update won't be useful
either. Note that there are two sides to the "natural key versus
surrogate key" issue and I'm not going to start or participate in Yet
Another Subthread on that issue.

Referential Integrity is, however, extremely useful even without either of
these options. It prevents entry of an erroneously keyed related record
and inadvertent deletion of a master record which has related records
prior to the related records being first deleted.

Relationships, even without Referential Integrity, can be convenient
(though minimally so) as the related fields are joined when you include
the related tables in a Query. You still have to set the Join type if it
is anything other than an "Inner Join" (only records where the field is
equal in both tables). And, I have been told, but never could determine
from real-world use, that there are performance improvements over just
Joining on the two fields in a Query.

Larry Linson
Microsoft Access MVP

Aug 22 '07 #12

P: n/a
ARC
Many thanks, Larry.

"Larry Linson" <bo*****@localhost.notwrote in message
news:0wKyi.2407$jy6.1538@trnddc01...
>
"ARC" <an**@andyc.comwrote
From what I've seen in my testing, and what
I've read myself, is that Access 2007, with all
it's major changes, is surprisingly stable.
That's what I have to hope anyway.

Good luck.

Larry Linson
Microsoft Access MVP


Aug 22 '07 #13

P: n/a
"ARC" <an**@andyc.comwrote
And I do remember reading about a bug, mainly with
importing relationships, and I wish I could give you
the source, but I can't, it's been years since I remember
reading about it. I wish I could back this up, but I can't.
I wasn't "demanding a cite," and don't doubt what you wrote. I'm sure it
was a bug, but one I never encountered (nor remember hearing about). I have
no doubt it has been solved and you aren't going to encounter it again (and
won't I be embarrassed when you post back and report that you _did_, with
later and/or updated releases?).
And thanks for your time to write the reply. I think from the
sounds of it, I should just use the enforce referential integrity,
and not check the cascade updates or deletes, that could, in fact,
be dangerous.
It can be problematical if the user has direct access to tables or queries,
or is allowed to delete master records from a form. If used as I described,
it can save a little development work. I sometimes, but rarely, use
Cascading Updates or Deletes.
And thanks for going easy on me!
Unless someone is violating the rules, or inadvertently, or (worse)
deliberately, misleading, I find that being patient is better for the
newsgroup, for the posters, and for my own peace of mind. There are those,
I suspect, who wouldn't agree with me fully or would chide me for not
following my own guidelines. :-)

Larry Linson
Microsoft Access MVP

Aug 22 '07 #14

P: n/a
"ARC" <an**@andyc.comwrote in
news:vH*******************@newssvr14.news.prodigy. net:
What I really need help with is when to use the cascade updates
and deletes. I'm still trying to understand this.
With Autonumber PKs, there is no need for CASCADE UPDATE, as the PK
values can't be changed. If you're using natural keys, then you
might need CASCADE UPDATE, but in that case, <KettleOfFish
class="open">I'd revisit the issue of using a natural
key</KettleOfFish>.

You seem to me to have gotten CASCADE DELETE about right. I often
think of lookups as being something different from child records,
even they they are just the same thing upside down. When I have a
dropdown list to populate a type that is used to classify records,
that's definitely one that you *don't* want CASCADE DELETE. But if
you're creating records in a subform that are children of the parent
form, those are definitely *possible* candidates for CASCADE DELETE.

From a relational theory point of view, there's no difference
between the two types, but the way we use them makes them seem very
different, and the difference seems to me to correspond very closely
to the line between when CASCADE DELETE is appropriate and when it
is not.

But I just formulated that idea, so maybe someone can point out
situations where it's obviously wrong.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 22 '07 #15

P: n/a
"ARC" <an**@andyc.comwrote in
news:FC******************@newssvr11.news.prodigy.n et:
I really saw the bug. As an example, we had a very large
reservation system, and in the example of the Guests table, in the
relationships window, I didn't just see Guest_1, Guests_2,
Guests_3, it went much much farther. The screen was literally full
of Guest_ iterations. And it seemed to multiply each time we
opened relationships.
Sounds to me like you were doing it wrong. You put the sintle table
there, and then have multiple relationships going to multiple
tables. The only time you'd have multiple aliases, seems to me,
would be when you have multiple columns in a single table that
relate to the same parent table, and that's a clear violation of
normalization.

So, it sounds to me like you encountered this problem in the RI
windows because of severe normalization problems.
So my boss made the call to remove all
relationships and I had never used them since. And I do remember
reading about a bug, mainly with importing relationships, and I
wish I could give you the source, but I can't, it's been years
since I remember reading about it. I wish I could back this up,
but I can't.
I've never encountered a bug in importing relationships along with
data tables.
And thanks for your time to write the reply. I think from the
sounds of it, I should just use the enforce referential integrity,
and not check the cascade updates or deletes, that could, in fact,
be dangerous.
Some of them are not dangerous, like in the quote situation you
described. Maybe my reply to you will help you see where it's good
and where it's not.
And thanks
for going easy on me! I was almost sorry I posted, as some replies
weren't so kind. I guess I just never used RE, and my program
actually had a minimum of orphaned data, and not the type that
were show-stoppers. In my mind, I always went though things
logically. It's like, ok the user wants to delete a quote. Confirm
the delete first, then delete the quote header record, ALL quote
detail records, and so-on. The user wants to delete a customer.
Ok, check for customer invoices, quotes, payments, if they exist,
prevent deletion. I never found manual RE (if there' such a thing)
to be that time consuming, but now I can see the benefits of
letting Access do it.
I've never coded any manual RI in Access. I had to do tons of it
Paradox, which I programmed before Access, and it was hellish. Thus,
when I had engine-level RI in Access, I gladly used it. The reasons
why your organization abandoned it seem to me to be remarkably
trivial and, well, almost childish.
I do need
to see how it does it, however, and make sure Access's messages to
the user make sense to them. Then I'll have to go through all my
code and see if I still need the manual RE coding. Yikes!
You still have to handle any violations of RI in your own code, but
the events are there and are triggered by Jet without you needing to
code anything. And that's the biggest time savings.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 22 '07 #16

P: n/a
Larry Linson wrote:
Unless someone is violating the rules, or inadvertently, or (worse)
deliberately, misleading, I find that being patient is better for the
newsgroup, for the posters, and for my own peace of mind. There are those,
I suspect, who wouldn't agree with me fully or would chide me for not
following my own guidelines. :-)
But if they disagreed with you Larry *they* would be wrong. Not everyone
has your patience and few have done more for this newsgroup.

--
'--------------------------
' John Mishefske
' UtterAccess Editor
' 2007 Microsoft Access MVP
'--------------------------
Aug 23 '07 #17

P: n/a
"ARC" <an**@andyc.comwrote in
news:AU***************@newssvr21.news.prodigy.net:
Where I'm really hosed is the few instances of "multi-use" type
tables. I posted in the relationships thread about this. I have an
addresses table that I use for both vendors and customers, but
it's only for additional contacts. So it has a CustVendID, and if
CustYN is checked, then CustVendID stores the CustID.
Customers and Vendors should be in the same table.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 23 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.