Table Design

[Stewart Allen]

Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of the
factory and the tblRegistration Data details when the machine was registered
after the customer buys it so the reason why the 1 -1 relationship. Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.

This design is now starting to kick me in the butt where I really notice it
now when my client wanted to be able to enter a claim against a machine if
it's unregistered if certain criteria was met. This wasn't foreseen a couple
of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date so
the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will be a
major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.

Stewart

[John Winterbottom]

Re: Table Design

"Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
news:c87m0k$gf4 $1@news.wave.co .nz...[color=blue]
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistratio nData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyDat a*
> WarrantyID (PK)
> RegID (FK) from tblRegistration Data
> ClaimDate
> "
> "
>
>
> How would you have designed the tables?[/color]


Probably with a single table.

[color=blue]
> I'll like to move all the fields from the tblRegistration Data to the
> tblBuildData to simplify the design and improve reporting but that will be[/color]
a[color=blue]
> major with modifying all objects in the database and SQL in code that use
> that table structure. About 350 objects.
>[/color]


One option is to move add the extra columns to tblBuildData, delete
tblRegistration Data then create a query called tblRegistration Data using
tblBuildData. That way your existing code would not break until you have the
time to go through and replace all references to the query.

[Larry Daugherty]

Re: Table Design

Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your
whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction
table makes sense in a many to many situation. As you have explained things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if
the back end is in Access. In this case, I'd be surprised if you're making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
news:c87m0k$gf4 $1@news.wave.co .nz...[color=blue]
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistratio nData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyDat a*
> WarrantyID (PK)
> RegID (FK) from tblRegistration Data
> ClaimDate
> "
> "
>
> tblBuildData details everything about the machine when it comes out of the
> factory and the tblRegistration Data details when the machine was[/color]
registered[color=blue]
> after the customer buys it so the reason why the 1 -1 relationship.[/color]
Warranty[color=blue]
> claims can only be made against machines that have been registered is
> another reason why the registration details are separate from the other
> machine data.
>
> This design is now starting to kick me in the butt where I really notice[/color]
it[color=blue]
> now when my client wanted to be able to enter a claim against a machine if
> it's unregistered if certain criteria was met. This wasn't foreseen a[/color]
couple[color=blue]
> of years ago was the system was designed. I got around this problem with
> code by inserting a date in the RegDate field and then deleting the date[/color]
so[color=blue]
> the AutoNumber was created for the tblWarrantyData could then create a
> record.
>
> How would you have designed the tables?
>
> I'll like to move all the fields from the tblRegistration Data to the
> tblBuildData to simplify the design and improve reporting but that will be[/color]
a[color=blue]
> major with modifying all objects in the database and SQL in code that use
> that table structure. About 350 objects.
>
> Stewart
>
>[/color]

[Stewart Allen]

Re: Table Design

Hi John,

A single table is also what I was thinking about. Creating new fields in the
tblBuild, deleting the tblRegistration and creating a query sounds good.

Stewart


"John Winterbottom" <assaynet@hotma il.com> wrote in message
news:2gpb0cF59d a5U1@uni-berlin.de...[color=blue]
> "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> news:c87m0k$gf4 $1@news.wave.co .nz...[color=green]
> > Hi
> >
> > Just asking for ideas on table design.
> >
> > The design I have is as follows:
> >
> > *tblBuildData*
> > BuildID (PK) AutoNumber
> > ManufactureDate
> > SerialNumber
> > "
> > "
> >
> > *tblRegistratio nData*
> > BuildID (PK) 1 - 1 from tblBuildData
> > RegID AutoNumber
> > RegDate
> > CustomerID
> > "
> > "
> >
> > *tblWarrantyDat a*
> > WarrantyID (PK)
> > RegID (FK) from tblRegistration Data
> > ClaimDate
> > "
> > "
> >
> >
> > How would you have designed the tables?[/color]
>
>
> Probably with a single table.
>
>[color=green]
> > I'll like to move all the fields from the tblRegistration Data to the
> > tblBuildData to simplify the design and improve reporting but that will[/color][/color]
be[color=blue]
> a[color=green]
> > major with modifying all objects in the database and SQL in code that[/color][/color]
use[color=blue][color=green]
> > that table structure. About 350 objects.
> >[/color]
>
>
> One option is to move add the extra columns to tblBuildData, delete
> tblRegistration Data then create a query called tblRegistration Data using
> tblBuildData. That way your existing code would not break until you have[/color]
the[color=blue]
> time to go through and replace all references to the query.
>
>
>
>[/color]

[Stewart Allen]

Re: Table Design

Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and then
recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is working
correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the new
copy of the front end.

Stewart


"Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
news:1BPpc.1327 22$G_.91118@nwr ddc02.gnilink.n et...[color=blue]
> Hi Stewart,
>
> If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
> after you remove referential integrity. As always, make a backup of your
> whole application before you start making changes. With the fields you
> currently have it, tblRegistration looks like a junction table. A[/color]
junction[color=blue]
> table makes sense in a many to many situation. As you have explained[/color]
things[color=blue]
> it's a logical part of tblBuild.
>
> If you make any changes to the schema there are likely to be changes
> propogating throughout your application. However it shouldn't be too bad[/color]
if[color=blue]
> the back end is in Access. In this case, I'd be surprised if you're[/color]
making[color=blue]
> any meaningful use of RegID.
>
> Are you aware that there are several that focus on specific parts of[/color]
Access,[color=blue]
> as well as this and another all-purpose Access newsgroup,
> Microsoft.publi c.access.*
>
> HTH
> --
> -Larry-
> --
>
> "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> news:c87m0k$gf4 $1@news.wave.co .nz...[color=green]
> > Hi
> >
> > Just asking for ideas on table design.
> >
> > The design I have is as follows:
> >
> > *tblBuildData*
> > BuildID (PK) AutoNumber
> > ManufactureDate
> > SerialNumber
> > "
> > "
> >
> > *tblRegistratio nData*
> > BuildID (PK) 1 - 1 from tblBuildData
> > RegID AutoNumber
> > RegDate
> > CustomerID
> > "
> > "
> >
> > *tblWarrantyDat a*
> > WarrantyID (PK)
> > RegID (FK) from tblRegistration Data
> > ClaimDate
> > "
> > "
> >
> > tblBuildData details everything about the machine when it comes out of[/color][/color]
the[color=blue][color=green]
> > factory and the tblRegistration Data details when the machine was[/color]
> registered[color=green]
> > after the customer buys it so the reason why the 1 -1 relationship.[/color]
> Warranty[color=green]
> > claims can only be made against machines that have been registered is
> > another reason why the registration details are separate from the other
> > machine data.
> >
> > This design is now starting to kick me in the butt where I really notice[/color]
> it[color=green]
> > now when my client wanted to be able to enter a claim against a machine[/color][/color]
if[color=blue][color=green]
> > it's unregistered if certain criteria was met. This wasn't foreseen a[/color]
> couple[color=green]
> > of years ago was the system was designed. I got around this problem with
> > code by inserting a date in the RegDate field and then deleting the date[/color]
> so[color=green]
> > the AutoNumber was created for the tblWarrantyData could then create a
> > record.
> >
> > How would you have designed the tables?
> >
> > I'll like to move all the fields from the tblRegistration Data to the
> > tblBuildData to simplify the design and improve reporting but that will[/color][/color]
be[color=blue]
> a[color=green]
> > major with modifying all objects in the database and SQL in code that[/color][/color]
use[color=blue][color=green]
> > that table structure. About 350 objects.
> >
> > Stewart
> >
> >[/color]
>
>[/color]

[Larry Daugherty]

Re: Table Design

Stewart,

Your planned approach is sound development practice except for the bit about
"on your time". Your company/client will be the beneficiary of the changes
you make. Why shouldn't company/client pay for the changes?

HTH
--
-Larry-
--

"Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
news:c88l51$ohb $3@news.wave.co .nz...[color=blue]
> Hi Larry,
>
> I intend to move all the fields from tblRegistration into tblBuild and[/color]
then[color=blue]
> recreate all the queries and SQL in code. The back end is
> Access which makes the process easier.
>
> What I might do is to start making the changes in my own time with my copy
> of the front end and a test copy of the back end. When everything is[/color]
working[color=blue]
> correctly, back up their copy of the data, add the fields and change the
> relationships and then run a couple of update queries then give them the[/color]
new[color=blue]
> copy of the front end.
>
> Stewart
>
>
> "Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
> news:1BPpc.1327 22$G_.91118@nwr ddc02.gnilink.n et...[color=green]
> > Hi Stewart,
> >
> > If tblRegistration is truly 1-1 with tblBuild then get rid of field[/color][/color]
RegID[color=blue][color=green]
> > after you remove referential integrity. As always, make a backup of[/color][/color]
your[color=blue][color=green]
> > whole application before you start making changes. With the fields you
> > currently have it, tblRegistration looks like a junction table. A[/color]
> junction[color=green]
> > table makes sense in a many to many situation. As you have explained[/color]
> things[color=green]
> > it's a logical part of tblBuild.
> >
> > If you make any changes to the schema there are likely to be changes
> > propogating throughout your application. However it shouldn't be too[/color][/color]
bad[color=blue]
> if[color=green]
> > the back end is in Access. In this case, I'd be surprised if you're[/color]
> making[color=green]
> > any meaningful use of RegID.
> >
> > Are you aware that there are several that focus on specific parts of[/color]
> Access,[color=green]
> > as well as this and another all-purpose Access newsgroup,
> > Microsoft.publi c.access.*
> >
> > HTH
> > --
> > -Larry-
> > --
> >
> > "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> > news:c87m0k$gf4 $1@news.wave.co .nz...[color=darkred]
> > > Hi
> > >
> > > Just asking for ideas on table design.
> > >
> > > The design I have is as follows:
> > >
> > > *tblBuildData*
> > > BuildID (PK) AutoNumber
> > > ManufactureDate
> > > SerialNumber
> > > "
> > > "
> > >
> > > *tblRegistratio nData*
> > > BuildID (PK) 1 - 1 from tblBuildData
> > > RegID AutoNumber
> > > RegDate
> > > CustomerID
> > > "
> > > "
> > >
> > > *tblWarrantyDat a*
> > > WarrantyID (PK)
> > > RegID (FK) from tblRegistration Data
> > > ClaimDate
> > > "
> > > "
> > >
> > > tblBuildData details everything about the machine when it comes out of[/color][/color]
> the[color=green][color=darkred]
> > > factory and the tblRegistration Data details when the machine was[/color]
> > registered[color=darkred]
> > > after the customer buys it so the reason why the 1 -1 relationship.[/color]
> > Warranty[color=darkred]
> > > claims can only be made against machines that have been registered is
> > > another reason why the registration details are separate from the[/color][/color][/color]
other[color=blue][color=green][color=darkred]
> > > machine data.
> > >
> > > This design is now starting to kick me in the butt where I really[/color][/color][/color]
notice[color=blue][color=green]
> > it[color=darkred]
> > > now when my client wanted to be able to enter a claim against a[/color][/color][/color]
machine[color=blue]
> if[color=green][color=darkred]
> > > it's unregistered if certain criteria was met. This wasn't foreseen a[/color]
> > couple[color=darkred]
> > > of years ago was the system was designed. I got around this problem[/color][/color][/color]
with[color=blue][color=green][color=darkred]
> > > code by inserting a date in the RegDate field and then deleting the[/color][/color][/color]
date[color=blue][color=green]
> > so[color=darkred]
> > > the AutoNumber was created for the tblWarrantyData could then create a
> > > record.
> > >
> > > How would you have designed the tables?
> > >
> > > I'll like to move all the fields from the tblRegistration Data to the
> > > tblBuildData to simplify the design and improve reporting but that[/color][/color][/color]
will[color=blue]
> be[color=green]
> > a[color=darkred]
> > > major with modifying all objects in the database and SQL in code that[/color][/color]
> use[color=green][color=darkred]
> > > that table structure. About 350 objects.
> > >
> > > Stewart
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Larry Daugherty]

Re: Table Design

I intended to mention about 2 emails back that there are some tools out
there that can be very helpful in making changes: Speed Ferret, a
commercial product and Find And Replace, a shareware product from Rick
Fisher. You can download Find And Replace from www.rickworld.com

--
-Larry-
--

"Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
news:c88l51$ohb $3@news.wave.co .nz...[color=blue]
> Hi Larry,
>
> I intend to move all the fields from tblRegistration into tblBuild and[/color]
then[color=blue]
> recreate all the queries and SQL in code. The back end is
> Access which makes the process easier.
>
> What I might do is to start making the changes in my own time with my copy
> of the front end and a test copy of the back end. When everything is[/color]
working[color=blue]
> correctly, back up their copy of the data, add the fields and change the
> relationships and then run a couple of update queries then give them the[/color]
new[color=blue]
> copy of the front end.
>
> Stewart
>
>
> "Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
> news:1BPpc.1327 22$G_.91118@nwr ddc02.gnilink.n et...[color=green]
> > Hi Stewart,
> >
> > If tblRegistration is truly 1-1 with tblBuild then get rid of field[/color][/color]
RegID[color=blue][color=green]
> > after you remove referential integrity. As always, make a backup of[/color][/color]
your[color=blue][color=green]
> > whole application before you start making changes. With the fields you
> > currently have it, tblRegistration looks like a junction table. A[/color]
> junction[color=green]
> > table makes sense in a many to many situation. As you have explained[/color]
> things[color=green]
> > it's a logical part of tblBuild.
> >
> > If you make any changes to the schema there are likely to be changes
> > propogating throughout your application. However it shouldn't be too[/color][/color]
bad[color=blue]
> if[color=green]
> > the back end is in Access. In this case, I'd be surprised if you're[/color]
> making[color=green]
> > any meaningful use of RegID.
> >
> > Are you aware that there are several that focus on specific parts of[/color]
> Access,[color=green]
> > as well as this and another all-purpose Access newsgroup,
> > Microsoft.publi c.access.*
> >
> > HTH
> > --
> > -Larry-
> > --
> >
> > "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> > news:c87m0k$gf4 $1@news.wave.co .nz...[color=darkred]
> > > Hi
> > >
> > > Just asking for ideas on table design.
> > >
> > > The design I have is as follows:
> > >
> > > *tblBuildData*
> > > BuildID (PK) AutoNumber
> > > ManufactureDate
> > > SerialNumber
> > > "
> > > "
> > >
> > > *tblRegistratio nData*
> > > BuildID (PK) 1 - 1 from tblBuildData
> > > RegID AutoNumber
> > > RegDate
> > > CustomerID
> > > "
> > > "
> > >
> > > *tblWarrantyDat a*
> > > WarrantyID (PK)
> > > RegID (FK) from tblRegistration Data
> > > ClaimDate
> > > "
> > > "
> > >
> > > tblBuildData details everything about the machine when it comes out of[/color][/color]
> the[color=green][color=darkred]
> > > factory and the tblRegistration Data details when the machine was[/color]
> > registered[color=darkred]
> > > after the customer buys it so the reason why the 1 -1 relationship.[/color]
> > Warranty[color=darkred]
> > > claims can only be made against machines that have been registered is
> > > another reason why the registration details are separate from the[/color][/color][/color]
other[color=blue][color=green][color=darkred]
> > > machine data.
> > >
> > > This design is now starting to kick me in the butt where I really[/color][/color][/color]
notice[color=blue][color=green]
> > it[color=darkred]
> > > now when my client wanted to be able to enter a claim against a[/color][/color][/color]
machine[color=blue]
> if[color=green][color=darkred]
> > > it's unregistered if certain criteria was met. This wasn't foreseen a[/color]
> > couple[color=darkred]
> > > of years ago was the system was designed. I got around this problem[/color][/color][/color]
with[color=blue][color=green][color=darkred]
> > > code by inserting a date in the RegDate field and then deleting the[/color][/color][/color]
date[color=blue][color=green]
> > so[color=darkred]
> > > the AutoNumber was created for the tblWarrantyData could then create a
> > > record.
> > >
> > > How would you have designed the tables?
> > >
> > > I'll like to move all the fields from the tblRegistration Data to the
> > > tblBuildData to simplify the design and improve reporting but that[/color][/color][/color]
will[color=blue]
> be[color=green]
> > a[color=darkred]
> > > major with modifying all objects in the database and SQL in code that[/color][/color]
> use[color=green][color=darkred]
> > > that table structure. About 350 objects.
> > >
> > > Stewart
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Stewart Allen]

Re: Table Design

I'll still plan charge them. What I mean by in my own time is that since I
have a copy of the front and back ends, I can do it in my own time if my
client wants the changes instead of travelling to their premises. I have no
intention to do this much work and not get paid for it.

Stewart

"Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
news:dZSpc.1338 19$G_.23596@nwr ddc02.gnilink.n et...[color=blue]
> Stewart,
>
> Your planned approach is sound development practice except for the bit[/color]
about[color=blue]
> "on your time". Your company/client will be the beneficiary of the[/color]
changes[color=blue]
> you make. Why shouldn't company/client pay for the changes?
>
> HTH
> --
> -Larry-
> --
>
> "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> news:c88l51$ohb $3@news.wave.co .nz...[color=green]
> > Hi Larry,
> >
> > I intend to move all the fields from tblRegistration into tblBuild and[/color]
> then[color=green]
> > recreate all the queries and SQL in code. The back end is
> > Access which makes the process easier.
> >
> > What I might do is to start making the changes in my own time with my[/color][/color]
copy[color=blue][color=green]
> > of the front end and a test copy of the back end. When everything is[/color]
> working[color=green]
> > correctly, back up their copy of the data, add the fields and change the
> > relationships and then run a couple of update queries then give them the[/color]
> new[color=green]
> > copy of the front end.
> >
> > Stewart
> >
> >
> > "Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
> > news:1BPpc.1327 22$G_.91118@nwr ddc02.gnilink.n et...[color=darkred]
> > > Hi Stewart,
> > >
> > > If tblRegistration is truly 1-1 with tblBuild then get rid of field[/color][/color]
> RegID[color=green][color=darkred]
> > > after you remove referential integrity. As always, make a backup of[/color][/color]
> your[color=green][color=darkred]
> > > whole application before you start making changes. With the fields[/color][/color][/color]
you[color=blue][color=green][color=darkred]
> > > currently have it, tblRegistration looks like a junction table. A[/color]
> > junction[color=darkred]
> > > table makes sense in a many to many situation. As you have explained[/color]
> > things[color=darkred]
> > > it's a logical part of tblBuild.
> > >
> > > If you make any changes to the schema there are likely to be changes
> > > propogating throughout your application. However it shouldn't be too[/color][/color]
> bad[color=green]
> > if[color=darkred]
> > > the back end is in Access. In this case, I'd be surprised if you're[/color]
> > making[color=darkred]
> > > any meaningful use of RegID.
> > >
> > > Are you aware that there are several that focus on specific parts of[/color]
> > Access,[color=darkred]
> > > as well as this and another all-purpose Access newsgroup,
> > > Microsoft.publi c.access.*
> > >
> > > HTH
> > > --
> > > -Larry-
> > > --
> > >
> > > "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> > > news:c87m0k$gf4 $1@news.wave.co .nz...
> > > > Hi
> > > >
> > > > Just asking for ideas on table design.
> > > >
> > > > The design I have is as follows:
> > > >
> > > > *tblBuildData*
> > > > BuildID (PK) AutoNumber
> > > > ManufactureDate
> > > > SerialNumber
> > > > "
> > > > "
> > > >
> > > > *tblRegistratio nData*
> > > > BuildID (PK) 1 - 1 from tblBuildData
> > > > RegID AutoNumber
> > > > RegDate
> > > > CustomerID
> > > > "
> > > > "
> > > >
> > > > *tblWarrantyDat a*
> > > > WarrantyID (PK)
> > > > RegID (FK) from tblRegistration Data
> > > > ClaimDate
> > > > "
> > > > "
> > > >
> > > > tblBuildData details everything about the machine when it comes out[/color][/color][/color]
of[color=blue][color=green]
> > the[color=darkred]
> > > > factory and the tblRegistration Data details when the machine was
> > > registered
> > > > after the customer buys it so the reason why the 1 -1 relationship.
> > > Warranty
> > > > claims can only be made against machines that have been registered[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > another reason why the registration details are separate from the[/color][/color]
> other[color=green][color=darkred]
> > > > machine data.
> > > >
> > > > This design is now starting to kick me in the butt where I really[/color][/color]
> notice[color=green][color=darkred]
> > > it
> > > > now when my client wanted to be able to enter a claim against a[/color][/color]
> machine[color=green]
> > if[color=darkred]
> > > > it's unregistered if certain criteria was met. This wasn't foreseen[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > couple
> > > > of years ago was the system was designed. I got around this problem[/color][/color]
> with[color=green][color=darkred]
> > > > code by inserting a date in the RegDate field and then deleting the[/color][/color]
> date[color=green][color=darkred]
> > > so
> > > > the AutoNumber was created for the tblWarrantyData could then create[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > > record.
> > > >
> > > > How would you have designed the tables?
> > > >
> > > > I'll like to move all the fields from the tblRegistration Data to the
> > > > tblBuildData to simplify the design and improve reporting but that[/color][/color]
> will[color=green]
> > be[color=darkred]
> > > a
> > > > major with modifying all objects in the database and SQL in code[/color][/color][/color]
that[color=blue][color=green]
> > use[color=darkred]
> > > > that table structure. About 350 objects.
> > > >
> > > > Stewart
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Stewart Allen]

Re: Table Design

Good idea. It would speed up the changes.

Stewart

"Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
news:S1Tpc.1338 49$G_.118065@nw rddc02.gnilink. net...[color=blue]
> I intended to mention about 2 emails back that there are some tools out
> there that can be very helpful in making changes: Speed Ferret, a
> commercial product and Find And Replace, a shareware product from Rick
> Fisher. You can download Find And Replace from www.rickworld.com
>
> --
> -Larry-
> --
>
> "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> news:c88l51$ohb $3@news.wave.co .nz...[color=green]
> > Hi Larry,
> >
> > I intend to move all the fields from tblRegistration into tblBuild and[/color]
> then[color=green]
> > recreate all the queries and SQL in code. The back end is
> > Access which makes the process easier.
> >
> > What I might do is to start making the changes in my own time with my[/color][/color]
copy[color=blue][color=green]
> > of the front end and a test copy of the back end. When everything is[/color]
> working[color=green]
> > correctly, back up their copy of the data, add the fields and change the
> > relationships and then run a couple of update queries then give them the[/color]
> new[color=green]
> > copy of the front end.
> >
> > Stewart
> >
> >
> > "Larry Daugherty" <Larry.NoSpam.D augherty@verizo n.net> wrote in message
> > news:1BPpc.1327 22$G_.91118@nwr ddc02.gnilink.n et...[color=darkred]
> > > Hi Stewart,
> > >
> > > If tblRegistration is truly 1-1 with tblBuild then get rid of field[/color][/color]
> RegID[color=green][color=darkred]
> > > after you remove referential integrity. As always, make a backup of[/color][/color]
> your[color=green][color=darkred]
> > > whole application before you start making changes. With the fields[/color][/color][/color]
you[color=blue][color=green][color=darkred]
> > > currently have it, tblRegistration looks like a junction table. A[/color]
> > junction[color=darkred]
> > > table makes sense in a many to many situation. As you have explained[/color]
> > things[color=darkred]
> > > it's a logical part of tblBuild.
> > >
> > > If you make any changes to the schema there are likely to be changes
> > > propogating throughout your application. However it shouldn't be too[/color][/color]
> bad[color=green]
> > if[color=darkred]
> > > the back end is in Access. In this case, I'd be surprised if you're[/color]
> > making[color=darkred]
> > > any meaningful use of RegID.
> > >
> > > Are you aware that there are several that focus on specific parts of[/color]
> > Access,[color=darkred]
> > > as well as this and another all-purpose Access newsgroup,
> > > Microsoft.publi c.access.*
> > >
> > > HTH
> > > --
> > > -Larry-
> > > --
> > >
> > > "Stewart Allen" <sagasu@NOT.wav e.THIS.co.nz> wrote in message
> > > news:c87m0k$gf4 $1@news.wave.co .nz...
> > > > Hi
> > > >
> > > > Just asking for ideas on table design.
> > > >
> > > > The design I have is as follows:
> > > >
> > > > *tblBuildData*
> > > > BuildID (PK) AutoNumber
> > > > ManufactureDate
> > > > SerialNumber
> > > > "
> > > > "
> > > >
> > > > *tblRegistratio nData*
> > > > BuildID (PK) 1 - 1 from tblBuildData
> > > > RegID AutoNumber
> > > > RegDate
> > > > CustomerID
> > > > "
> > > > "
> > > >
> > > > *tblWarrantyDat a*
> > > > WarrantyID (PK)
> > > > RegID (FK) from tblRegistration Data
> > > > ClaimDate
> > > > "
> > > > "
> > > >
> > > > tblBuildData details everything about the machine when it comes out[/color][/color][/color]
of[color=blue][color=green]
> > the[color=darkred]
> > > > factory and the tblRegistration Data details when the machine was
> > > registered
> > > > after the customer buys it so the reason why the 1 -1 relationship.
> > > Warranty
> > > > claims can only be made against machines that have been registered[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > another reason why the registration details are separate from the[/color][/color]
> other[color=green][color=darkred]
> > > > machine data.
> > > >
> > > > This design is now starting to kick me in the butt where I really[/color][/color]
> notice[color=green][color=darkred]
> > > it
> > > > now when my client wanted to be able to enter a claim against a[/color][/color]
> machine[color=green]
> > if[color=darkred]
> > > > it's unregistered if certain criteria was met. This wasn't foreseen[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > couple
> > > > of years ago was the system was designed. I got around this problem[/color][/color]
> with[color=green][color=darkred]
> > > > code by inserting a date in the RegDate field and then deleting the[/color][/color]
> date[color=green][color=darkred]
> > > so
> > > > the AutoNumber was created for the tblWarrantyData could then create[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > > record.
> > > >
> > > > How would you have designed the tables?
> > > >
> > > > I'll like to move all the fields from the tblRegistration Data to the
> > > > tblBuildData to simplify the design and improve reporting but that[/color][/color]
> will[color=green]
> > be[color=darkred]
> > > a
> > > > major with modifying all objects in the database and SQL in code[/color][/color][/color]
that[color=blue][color=green]
> > use[color=darkred]
> > > > that table structure. About 350 objects.
> > > >
> > > > Stewart
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]