From charlotte.foust at gmail.com  Fri Aug  1 13:00:59 2014
From: charlotte.foust at gmail.com (Charlotte Foust)
Date: Fri, 1 Aug 2014 11:00:59 -0700
Subject: [AccessD] Fisher Find & Replace
In-Reply-To: <CAJLzs_01w2+aEtg6yrMz7WLAsqXRQBjeHDL9veX-5Bb=PaA6vw@mail.gmail.com>
References: <002701cfac47$560b2460$02216d20$@dalyn.co.nz>
	<CAJLzs_19cSKaehrGvv7L2SHpRFFoaO9h3J-eYeJAAen1S96e4w@mail.gmail.com>
	<003201cfac4b$46b05680$d4110380$@dalyn.co.nz>
	<89278527c6fc4c06a357987dc0691454@HKXPR04MB360.apcprd04.prod.outlook.com>
	<53D98864.7060501@internode.on.net>
	<49B0CCC8180740898073C8A8183F32A3@HAL9007>
	<CAH+Met-VZ5HVamYSALgo2tUcr8qsintjnpD0WjN99G0vr2bJcQ@mail.gmail.com>
	<CAJLzs_01w2+aEtg6yrMz7WLAsqXRQBjeHDL9veX-5Bb=PaA6vw@mail.gmail.com>
Message-ID: <CAH+Met9ziiQuJh-1bJBb7BKmW7fa_nTKcT8BYPXaS-J4eMg_fw@mail.gmail.com>

It won't run on my machine with Office 2013.  Doesn't turn up as an add-in
and doesn't work.

Charlotte


On Thu, Jul 31, 2014 at 2:30 PM, Bill Benson <bensonforums at gmail.com> wrote:

> At all?
> On Jul 31, 2014 12:45 PM, "Charlotte Foust" <charlotte.foust at gmail.com>
> wrote:
>
> > Doesn't work on 2013.
> >
> > Charlotte
> >
> >
> > On Wed, Jul 30, 2014 at 10:27 PM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > The best danged utility ever given to an Access developer:
> > > http://www.rickworld.com/products.html
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan
> > > Fitzpatrick
> > > Sent: Wednesday, July 30, 2014 5:06 PM
> > > To: Access Developers discussion and problem solving
> > > Subject: Re: [AccessD] Fisher Find & Replace
> > >
> > > Out of curiosity, what is Find and Replace?  I assume a utility program
> > of
> > > some kind?
> > >
> > > Cheers
> > > */Bryan Fitzpatrick
> > > Mobile: 0418 618 469/*
> > > On 31/07/2014 9:36 AM, Darryl Collins wrote:
> > > > Hi David,
> > > >
> > > > I have Find and replace - never used it update headers or colours
> > though.
> > > Not sure it can do that as it is mostly geared to updating names and/or
> > > properties rather than colours - although you could always send Rick an
> > > email and ask.  The few times I have needed to contact him he has
> always
> > > gotten back promptly with an answer.
> > > >
> > > > Cheers
> > > > Darryl.
> > > >
> > > > -----Original Message-----
> > > > From: accessd-bounces at databaseadvisors.com
> > > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David
> > > > Emerson
> > > > Sent: Thursday, 31 July 2014 9:09 AM
> > > > To: 'Access Developers discussion and problem solving'
> > > > Subject: Re: [AccessD] Fisher Find & Replace
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > The changes are only to form header and detail colors.  I suppose I
> > could
> > > write code to do this but I hoped it would already be within Rick's
> tool.
> > > >
> > > > Otherwise it may be quicker just to make the changes manually to each
> > > form
> > > (about 100).
> > > >
> > > > Regards
> > > >
> > > > David
> > > >
> > > > -----Original Message-----
> > > > From: accessd-bounces at databaseadvisors.com
> > > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill
> Benson
> > > > Sent: Thursday, 31 July 2014 10:57 a.m.
> > > > To: Access Developers discussion and problem solving
> > > > Subject: Re: [AccessD] Fisher Find & Replace
> > > >
> > > > Hi David. I don't know about that program's capabilities but would
> you
> > > not
> > > be able to do this somewhat simply with VBA?..
> > > >
> > > > With a form open, identify all controls in that Section, check that
> > > > TypeName = "Textbox", and set the background color and / or however
> > > > that theme manifests, to whatever value(s) look right in a control
> you
> > > > have manually set. The parent hierarchy is
> > > >
> > > > Docmd.open acform, theformname, acDesigh (I think.... can't test from
> > > > where I am now)
> > > >
> > > > This is air code and I might not have the correct index for header
> > > section.
> > > >
> > > > For each ctrl in Screen.ActiveForm.sections (0).controls
> > > >       With curl
> > > > ...
> > > >
> > > >        End with
> > > > Next
> > > >
> > > >
> > > > At least this is how I would go about trying to do it anyway. Shame
> > there
> > > is no Macro recorder in Access!
> > > > On Jul 30, 2014 6:42 PM, "David Emerson" <newsgrps at dalyn.co.nz>
> wrote:
> > > >
> > > >> Hi Listers,
> > > >>
> > > >>
> > > >>
> > > >> I Have Rick's Find and Replace version 9.00k.  I need to change the
> > > >> form section (header and detail) background colors for all the forms
> > > >> in my Access 2010 database.
> > > >>
> > > >>
> > > >>
> > > >> I have tried playing with the Search User Specified Properties
> > > >> section but am not coming up with any matches (let alone being able
> > > >> to change
> > > > them).
> > > >>
> > > >>
> > > >> The objective is to eventually replace several control fields with
> > > >> Theme colours.
> > > >>
> > > >>
> > > >>
> > > >> Does anyone have any pointers?
> > > >>
> > > >>
> > > >>
> > > >> Regards
> > > >>
> > > >> David Emerson
> > > >> Dalyn Software Ltd
> > > >> Wellington, New Zealand
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> AccessD mailing list
> > > >> AccessD at databaseadvisors.com
> > > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> Website: http://www.databaseadvisors.com
> > > >>
> > > > --
> > > > AccessD mailing list
> > > > AccessD at databaseadvisors.com
> > > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > > Website: http://www.databaseadvisors.com
> > > >
> > > > --
> > > > AccessD mailing list
> > > > AccessD at databaseadvisors.com
> > > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > > Website: http://www.databaseadvisors.com
> > > >
> > >
> > >
> > >
> > >
> > > -----
> > > No virus found in this message.
> > > Checked by AVG - www.avg.com
> > > Version: 2014.0.4716 / Virus Database: 3986/7951 - Release Date:
> 07/30/14
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From charlotte.foust at gmail.com  Fri Aug  1 13:04:02 2014
From: charlotte.foust at gmail.com (Charlotte Foust)
Date: Fri, 1 Aug 2014 11:04:02 -0700
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>
	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>
	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>
	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>
	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>
Message-ID: <CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>

Remember, though, that's for display purposes.  If you want the value to
get into a new record, you need to use the field default.

Charlotte


On Thu, Jul 31, 2014 at 10:47 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> I'll probably use the default on the control - it'll be easier since I can
> define one checkbox and clone it x times.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
> Sent: Thursday, July 31, 2014 9:47 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Creating default false in yes/no field
>
> Are you talking about the field or the checkbox control?  I customarily set
> the field to a zero default, but the control handles a triple-state answer
> so you have to set its default as well.  I can't recall if I've ever tried
> to set the control default using a normal form with a checkbox control, but
> it's worth a try.
>
> Charlotte
>
> Charlotte
>
>
> On Thu, Jul 31, 2014 at 8:16 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
>
> > Yeah I can do that for each field I create but if there's a way to set
> > False as the default it would save a lot of tedious keystrokes and
> > mouse clicks.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
> > Sent: Thursday, July 31, 2014 8:14 AM
> > To: 'Access Developers discussion and problem solving'
> > Subject: Re: [AccessD] Creating default false in yes/no field
> >
> > Hi Rocky,
> >
> > In the property screen for a yes/no field just enter True or False as
> > the default value.
> >
> > Dan
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky
> > Smolin
> > Sent: Thursday, July 31, 2014 10:02 AM
> > To: 'Access Developers discussion and problem solving'; 'Off Topic'
> > Subject: [AccessD] Creating default false in yes/no field
> >
> > Dear List:
> >
> > Is there a way to set the default of a yes/no field in a table when
> > creating that field in design view.  I am using A2003 and the default
> > appears to be null.
> >
> > MTIA
> >
> > Rocky Smolin
> > Beach Access Software
> > 858-259-4334
> > www.bchacc.com <http://www.bchacc.com/> www.e-z-mrp.com
> > <http://www.e-z-mrp.com/>
> > Skype: rocky.smolin
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From rockysmolin at bchacc.com  Fri Aug  1 13:13:03 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 1 Aug 2014 11:13:03 -0700
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007><BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl><A841E2A287874219ACCF46E3DA2107D3@HAL9007><CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com><CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>
	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>
Message-ID: <F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>

When the new record is updated to the table, if the default of the control
if false, I'm thinking that the default of the control will set the value of
the field in the record to false.

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Friday, August 01, 2014 11:04 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Remember, though, that's for display purposes.  If you want the value to get
into a new record, you need to use the field default.

Charlotte


On Thu, Jul 31, 2014 at 10:47 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> I'll probably use the default on the control - it'll be easier since I 
> can define one checkbox and clone it x times.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte 
> Foust
> Sent: Thursday, July 31, 2014 9:47 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Creating default false in yes/no field
>
> Are you talking about the field or the checkbox control?  I 
> customarily set the field to a zero default, but the control handles a 
> triple-state answer so you have to set its default as well.  I can't 
> recall if I've ever tried to set the control default using a normal 
> form with a checkbox control, but it's worth a try.
>
> Charlotte
>
> Charlotte
>
>
> On Thu, Jul 31, 2014 at 8:16 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
>
> > Yeah I can do that for each field I create but if there's a way to 
> > set False as the default it would save a lot of tedious keystrokes 
> > and mouse clicks.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan 
> > Waters
> > Sent: Thursday, July 31, 2014 8:14 AM
> > To: 'Access Developers discussion and problem solving'
> > Subject: Re: [AccessD] Creating default false in yes/no field
> >
> > Hi Rocky,
> >
> > In the property screen for a yes/no field just enter True or False 
> > as the default value.
> >
> > Dan
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky 
> > Smolin
> > Sent: Thursday, July 31, 2014 10:02 AM
> > To: 'Access Developers discussion and problem solving'; 'Off Topic'
> > Subject: [AccessD] Creating default false in yes/no field
> >
> > Dear List:
> >
> > Is there a way to set the default of a yes/no field in a table when 
> > creating that field in design view.  I am using A2003 and the 
> > default appears to be null.
> >
> > MTIA
> >
> > Rocky Smolin
> > Beach Access Software
> > 858-259-4334
> > www.bchacc.com <http://www.bchacc.com/> www.e-z-mrp.com 
> > <http://www.e-z-mrp.com/>
> > Skype: rocky.smolin
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From charlotte.foust at gmail.com  Fri Aug  1 15:59:46 2014
From: charlotte.foust at gmail.com (Charlotte Foust)
Date: Fri, 1 Aug 2014 13:59:46 -0700
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>
	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>
	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>
	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>
	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>
	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>
	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
Message-ID: <CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>

I'm honestly not sure, Rocky.  I just never take chances!  LOL

Charlotte


On Fri, Aug 1, 2014 at 11:13 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> When the new record is updated to the table, if the default of the control
> if false, I'm thinking that the default of the control will set the value
> of
> the field in the record to false.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
> Sent: Friday, August 01, 2014 11:04 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Creating default false in yes/no field
>
> Remember, though, that's for display purposes.  If you want the value to
> get
> into a new record, you need to use the field default.
>
> Charlotte
>
>
> On Thu, Jul 31, 2014 at 10:47 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
>
> > I'll probably use the default on the control - it'll be easier since I
> > can define one checkbox and clone it x times.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
> > Foust
> > Sent: Thursday, July 31, 2014 9:47 AM
> > To: Access Developers discussion and problem solving
> > Subject: Re: [AccessD] Creating default false in yes/no field
> >
> > Are you talking about the field or the checkbox control?  I
> > customarily set the field to a zero default, but the control handles a
> > triple-state answer so you have to set its default as well.  I can't
> > recall if I've ever tried to set the control default using a normal
> > form with a checkbox control, but it's worth a try.
> >
> > Charlotte
> >
> > Charlotte
> >
> >
> > On Thu, Jul 31, 2014 at 8:16 AM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Yeah I can do that for each field I create but if there's a way to
> > > set False as the default it would save a lot of tedious keystrokes
> > > and mouse clicks.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan
> > > Waters
> > > Sent: Thursday, July 31, 2014 8:14 AM
> > > To: 'Access Developers discussion and problem solving'
> > > Subject: Re: [AccessD] Creating default false in yes/no field
> > >
> > > Hi Rocky,
> > >
> > > In the property screen for a yes/no field just enter True or False
> > > as the default value.
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky
> > > Smolin
> > > Sent: Thursday, July 31, 2014 10:02 AM
> > > To: 'Access Developers discussion and problem solving'; 'Off Topic'
> > > Subject: [AccessD] Creating default false in yes/no field
> > >
> > > Dear List:
> > >
> > > Is there a way to set the default of a yes/no field in a table when
> > > creating that field in design view.  I am using A2003 and the
> > > default appears to be null.
> > >
> > > MTIA
> > >
> > > Rocky Smolin
> > > Beach Access Software
> > > 858-259-4334
> > > www.bchacc.com <http://www.bchacc.com/> www.e-z-mrp.com
> > > <http://www.e-z-mrp.com/>
> > > Skype: rocky.smolin
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From rockysmolin at bchacc.com  Fri Aug  1 20:24:01 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 1 Aug 2014 18:24:01 -0700
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007><BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl><A841E2A287874219ACCF46E3DA2107D3@HAL9007><CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com><CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007><CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com><F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>
Message-ID: <106108AE4DE54288BF486187FD91070D@HAL9007>

I'll find out soon enough.  Actually, with a few lines of code I could
change all of those fields in all the tables en masse.

r 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Friday, August 01, 2014 2:00 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

I'm honestly not sure, Rocky.  I just never take chances!  LOL

Charlotte


On Fri, Aug 1, 2014 at 11:13 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> When the new record is updated to the table, if the default of the 
> control if false, I'm thinking that the default of the control will 
> set the value of the field in the record to false.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte 
> Foust
> Sent: Friday, August 01, 2014 11:04 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Creating default false in yes/no field
>
> Remember, though, that's for display purposes.  If you want the value 
> to get into a new record, you need to use the field default.
>
> Charlotte
>
>
> On Thu, Jul 31, 2014 at 10:47 AM, Rocky Smolin 
> <rockysmolin at bchacc.com>
> wrote:
>
> > I'll probably use the default on the control - it'll be easier since 
> > I can define one checkbox and clone it x times.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte 
> > Foust
> > Sent: Thursday, July 31, 2014 9:47 AM
> > To: Access Developers discussion and problem solving
> > Subject: Re: [AccessD] Creating default false in yes/no field
> >
> > Are you talking about the field or the checkbox control?  I 
> > customarily set the field to a zero default, but the control handles 
> > a triple-state answer so you have to set its default as well.  I 
> > can't recall if I've ever tried to set the control default using a 
> > normal form with a checkbox control, but it's worth a try.
> >
> > Charlotte
> >
> > Charlotte
> >
> >
> > On Thu, Jul 31, 2014 at 8:16 AM, Rocky Smolin 
> > <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Yeah I can do that for each field I create but if there's a way to 
> > > set False as the default it would save a lot of tedious keystrokes 
> > > and mouse clicks.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan 
> > > Waters
> > > Sent: Thursday, July 31, 2014 8:14 AM
> > > To: 'Access Developers discussion and problem solving'
> > > Subject: Re: [AccessD] Creating default false in yes/no field
> > >
> > > Hi Rocky,
> > >
> > > In the property screen for a yes/no field just enter True or False 
> > > as the default value.
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky 
> > > Smolin
> > > Sent: Thursday, July 31, 2014 10:02 AM
> > > To: 'Access Developers discussion and problem solving'; 'Off Topic'
> > > Subject: [AccessD] Creating default false in yes/no field
> > >
> > > Dear List:
> > >
> > > Is there a way to set the default of a yes/no field in a table 
> > > when creating that field in design view.  I am using A2003 and the 
> > > default appears to be null.
> > >
> > > MTIA
> > >
> > > Rocky Smolin
> > > Beach Access Software
> > > 858-259-4334
> > > www.bchacc.com <http://www.bchacc.com/> www.e-z-mrp.com 
> > > <http://www.e-z-mrp.com/>
> > > Skype: rocky.smolin
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Fri Aug  1 20:31:54 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 1 Aug 2014 21:31:54 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <106108AE4DE54288BF486187FD91070D@HAL9007>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007><BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl><A841E2A287874219ACCF46E3DA2107D3@HAL9007><CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com><CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007><CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com><F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>
	<106108AE4DE54288BF486187FD91070D@HAL9007>
Message-ID: <007601cfadf1$8bcc4f60$a364ee20$@gmail.com>

I don't follow this thread completely, but in my recent project I have a
yes/no field in the database called Inactive, whose default is 0. How I
maintain that on the form is that I drag that field onto the form, and make
it invisible. I then have an Option Group (Frame) control with two Option
Buttons:  
	Control		Value
	optActive	1
	optInactive	2

On Current, I populate the controls as:

Private Sub Form_Current()
If InActive = False Then
    frStatus = 1
Else
    frStatus = 2
End If
End Sub

And when the controls are updated I populate the field as:

Private Sub frStatus_AfterUpdate()
	InActive = IIf(frStatus.Value = 1, False, True)
End Sub

If this is unrelated to what you are dealing with, I apologize.


From steve at datamanagementsolutions.biz  Sat Aug  2 15:12:38 2014
From: steve at datamanagementsolutions.biz (Steve Schapel)
Date: Sun, 3 Aug 2014 08:12:38 +1200
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <007601cfadf1$8bcc4f60$a364ee20$@gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007><BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl><A841E2A287874219ACCF46E3DA2107D3@HAL9007><CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com><CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007><CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com><F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com><106108AE4DE54288BF486187FD91070D@HAL9007>
	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>
Message-ID: <211E2C8B32234B8387A7F01494F407E7@SteveT540p>

Bill

You could have saved yourself a bit of trouble here by simply binding the 
option group to the Yes/No field, and setting the Option Value of the option 
buttons to -1 and 0.

No hidden control, no code.

Regards
Steve


-----Original Message----- 
From: Bill Benson
Sent: Saturday, August 2, 2014 1:31 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I don't follow this thread completely, but in my recent project I have a
yes/no field in the database called Inactive, whose default is 0. How I
maintain that on the form is that I drag that field onto the form, and make
it invisible. I then have an Option Group (Frame) control with two Option
Buttons:
Control Value
optActive 1
optInactive 2

On Current, I populate the controls as:

Private Sub Form_Current()
If InActive = False Then
    frStatus = 1
Else
    frStatus = 2
End If
End Sub

And when the controls are updated I populate the field as:

Private Sub frStatus_AfterUpdate()
InActive = IIf(frStatus.Value = 1, False, True)
End Sub

If this is unrelated to what you are dealing with, I apologize.

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 


From steve at datamanagementsolutions.biz  Sat Aug  2 15:14:20 2014
From: steve at datamanagementsolutions.biz (Steve Schapel)
Date: Sun, 3 Aug 2014 08:14:20 +1200
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007><BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl><A841E2A287874219ACCF46E3DA2107D3@HAL9007><CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com><CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007><CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>
	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
Message-ID: <1F950D12327B451D894175C0975D0834@SteveT540p>

Yes, it will Rocky.  In that sense, it is no different from the default 
value behaviour of any other type of control.

Regards
Steve

-----Original Message----- 
From: Rocky Smolin
Sent: Saturday, August 2, 2014 6:13 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

When the new record is updated to the table, if the default of the control
if false, I'm thinking that the default of the control will set the value of
the field in the record to false.

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Friday, August 01, 2014 11:04 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Remember, though, that's for display purposes.  If you want the value to get
into a new record, you need to use the field default.

Charlotte


On Thu, Jul 31, 2014 at 10:47 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> I'll probably use the default on the control - it'll be easier since I
> can define one checkbox and clone it x times.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
> Foust
> Sent: Thursday, July 31, 2014 9:47 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Creating default false in yes/no field
>
> Are you talking about the field or the checkbox control?  I
> customarily set the field to a zero default, but the control handles a
> triple-state answer so you have to set its default as well.  I can't
> recall if I've ever tried to set the control default using a normal
> form with a checkbox control, but it's worth a try.
>
> Charlotte
>
> Charlotte
>
>
> On Thu, Jul 31, 2014 at 8:16 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
>
> > Yeah I can do that for each field I create but if there's a way to
> > set False as the default it would save a lot of tedious keystrokes
> > and mouse clicks.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan
> > Waters
> > Sent: Thursday, July 31, 2014 8:14 AM
> > To: 'Access Developers discussion and problem solving'
> > Subject: Re: [AccessD] Creating default false in yes/no field
> >
> > Hi Rocky,
> >
> > In the property screen for a yes/no field just enter True or False
> > as the default value.
> >
> > Dan
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky
> > Smolin
> > Sent: Thursday, July 31, 2014 10:02 AM
> > To: 'Access Developers discussion and problem solving'; 'Off Topic'
> > Subject: [AccessD] Creating default false in yes/no field
> >
> > Dear List:
> >
> > Is there a way to set the default of a yes/no field in a table when
> > creating that field in design view.  I am using A2003 and the
> > default appears to be null.
> >
> > MTIA
> >
> > Rocky Smolin
> > Beach Access Software
> > 858-259-4334
> > www.bchacc.com <http://www.bchacc.com/> www.e-z-mrp.com
> > <http://www.e-z-mrp.com/>
> > Skype: rocky.smolin
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 


From bensonforums at gmail.com  Sat Aug  2 15:20:31 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Sat, 2 Aug 2014 16:20:31 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <211E2C8B32234B8387A7F01494F407E7@SteveT540p>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>
	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>
	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>
	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>
	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>
	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>
	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>
	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>
	<106108AE4DE54288BF486187FD91070D@HAL9007>
	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>
	<211E2C8B32234B8387A7F01494F407E7@SteveT540p>
Message-ID: <CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>

Wow Steve, I did not know I could give option buttons values.. This is a
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz>
wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding the
option group to the Yes/No field, and setting the Option Value of the
option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

From dw-murphy at cox.net  Sat Aug  2 17:59:53 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Sat, 2 Aug 2014 15:59:53 -0700
Subject: [AccessD] Fisher Find & Replace
In-Reply-To: <Ymiw1o01X0xgD8Z01miyBV>
References: <Ymiw1o01X0xgD8Z01miyBV>
Message-ID: <001501cfaea5$78d7f710$6a87e530$@cox.net>

Helen Feddema has a routine on her example site,
http://www.helenfeddema.com/Code%20Samples.htm,  that will allow changing
all the header, footer and detail portion form color properties to user
specified values.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Wednesday, July 30, 2014 3:41 PM
To: AccessD
Subject: [AccessD] Fisher Find & Replace

Hi Listers,

 

I Have Rick's Find and Replace version 9.00k.  I need to change the form
section (header and detail) background colors for all the forms in my Access
2010 database.

 

I have tried playing with the Search User Specified Properties section but
am not coming up with any matches (let alone being able to change them).

 

The objective is to eventually replace several control fields with Theme
colours.

 

Does anyone have any pointers?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

 

 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From newsgrps at dalyn.co.nz  Sat Aug  2 23:15:22 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Sun, 3 Aug 2014 16:15:22 +1200
Subject: [AccessD] Fisher Find & Replace
In-Reply-To: <001501cfaea5$78d7f710$6a87e530$@cox.net>
References: <Ymiw1o01X0xgD8Z01miyBV> <001501cfaea5$78d7f710$6a87e530$@cox.net>
Message-ID: <000601cfaed1$8ba889f0$a2f99dd0$@dalyn.co.nz>

Hi Doug,

Thanks for the tip.  I could only see some code for 2003 and earlier
versions.  Do you have the Code sample number you are referring to?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Sunday, 3 August 2014 11:00 a.m.
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Helen Feddema has a routine on her example site,
http://www.helenfeddema.com/Code%20Samples.htm,  that will allow changing
all the header, footer and detail portion form color properties to user
specified values.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Wednesday, July 30, 2014 3:41 PM
To: AccessD
Subject: [AccessD] Fisher Find & Replace

Hi Listers,

 

I Have Rick's Find and Replace version 9.00k.  I need to change the form
section (header and detail) background colors for all the forms in my Access
2010 database.

 

I have tried playing with the Search User Specified Properties section but
am not coming up with any matches (let alone being able to change them).

 

The objective is to eventually replace several control fields with Theme
colours.

 

Does anyone have any pointers?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

 

 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From dw-murphy at cox.net  Sun Aug  3 12:30:32 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Sun, 3 Aug 2014 10:30:32 -0700
Subject: [AccessD] Fisher Find & Replace
In-Reply-To: <a4HC1o00c0xgD8Z014HF3Z>
References: <Ymiw1o01X0xgD8Z01miyBV> <001501cfaea5$78d7f710$6a87e530$@cox.net>
	<a4HC1o00c0xgD8Z014HF3Z>
Message-ID: <002a01cfaf40$a08c22e0$e1a468a0$@cox.net>

David,

I would expect that this will work with versions atleast through 2010. VBA
and form properties have not changed that much as long as you working with
mdb/accdb files.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Saturday, August 02, 2014 9:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Hi Doug,

Thanks for the tip.  I could only see some code for 2003 and earlier
versions.  Do you have the Code sample number you are referring to?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Sunday, 3 August 2014 11:00 a.m.
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Helen Feddema has a routine on her example site,
http://www.helenfeddema.com/Code%20Samples.htm,  that will allow changing
all the header, footer and detail portion form color properties to user
specified values.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Wednesday, July 30, 2014 3:41 PM
To: AccessD
Subject: [AccessD] Fisher Find & Replace

Hi Listers,

 

I Have Rick's Find and Replace version 9.00k.  I need to change the form
section (header and detail) background colors for all the forms in my Access
2010 database.

 

I have tried playing with the Search User Specified Properties section but
am not coming up with any matches (let alone being able to change them).

 

The objective is to eventually replace several control fields with Theme
colours.

 

Does anyone have any pointers?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

 

 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From df.waters at outlook.com  Sun Aug  3 13:20:48 2014
From: df.waters at outlook.com (Dan Waters)
Date: Sun, 3 Aug 2014 13:20:48 -0500
Subject: [AccessD] Fisher Find & Replace
Message-ID: <BLU405-EAS168D5BCBB5FC905A9CCE4CBF6E50@phx.gbl>

I use F&R with Access 2010 frequently - it works just fine.

Dan

Sent from my cell phone
________________________________
From: Doug Murphy<mailto:dw-murphy at cox.net>
Sent: ?8/?3/?2014 12:32
To: 'Access Developers discussion and problem solving'<mailto:accessd at databaseadvisors.com>
Subject: Re: [AccessD] Fisher Find & Replace

David,

I would expect that this will work with versions atleast through 2010. VBA
and form properties have not changed that much as long as you working with
mdb/accdb files.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Saturday, August 02, 2014 9:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Hi Doug,

Thanks for the tip.  I could only see some code for 2003 and earlier
versions.  Do you have the Code sample number you are referring to?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Sunday, 3 August 2014 11:00 a.m.
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Helen Feddema has a routine on her example site,
http://www.helenfeddema.com/Code%20Samples.htm,  that will allow changing
all the header, footer and detail portion form color properties to user
specified values.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Wednesday, July 30, 2014 3:41 PM
To: AccessD
Subject: [AccessD] Fisher Find & Replace

Hi Listers,



I Have Rick's Find and Replace version 9.00k.  I need to change the form
section (header and detail) background colors for all the forms in my Access
2010 database.



I have tried playing with the Search User Specified Properties section but
am not coming up with any matches (let alone being able to change them).



The objective is to eventually replace several control fields with Theme
colours.



Does anyone have any pointers?



Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand





--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

From dw-murphy at cox.net  Sun Aug  3 14:22:18 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Sun, 3 Aug 2014 12:22:18 -0700
Subject: [AccessD] Fisher Find & Replace
In-Reply-To: <aJNP1o00D0xgD8Z01JNRdy>
References: <aJNP1o00D0xgD8Z01JNRdy>
Message-ID: <002b01cfaf50$3dadf990$b909ecb0$@cox.net>

Subject changed. We were discussing whether Helen's code would work in versions after 2003.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, August 03, 2014 11:21 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Fisher Find & Replace

I use F&R with Access 2010 frequently - it works just fine.

Dan

Sent from my cell phone
________________________________
From: Doug Murphy<mailto:dw-murphy at cox.net>
Sent: ?8/?3/?2014 12:32
To: 'Access Developers discussion and problem solving'<mailto:accessd at databaseadvisors.com>
Subject: Re: [AccessD] Fisher Find & Replace

David,

I would expect that this will work with versions atleast through 2010. VBA and form properties have not changed that much as long as you working with mdb/accdb files.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Saturday, August 02, 2014 9:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Hi Doug,

Thanks for the tip.  I could only see some code for 2003 and earlier versions.  Do you have the Code sample number you are referring to?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Sunday, 3 August 2014 11:00 a.m.
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Fisher Find & Replace

Helen Feddema has a routine on her example site, http://www.helenfeddema.com/Code%20Samples.htm,  that will allow changing all the header, footer and detail portion form color properties to user specified values.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Wednesday, July 30, 2014 3:41 PM
To: AccessD
Subject: [AccessD] Fisher Find & Replace

Hi Listers,



I Have Rick's Find and Replace version 9.00k.  I need to change the form section (header and detail) background colors for all the forms in my Access
2010 database.



I have tried playing with the Search User Specified Properties section but am not coming up with any matches (let alone being able to change them).



The objective is to eventually replace several control fields with Theme colours.



Does anyone have any pointers?



Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand





--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From bensonforums at gmail.com  Tue Aug  5 21:15:40 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Tue, 5 Aug 2014 22:15:40 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p>
	<CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>
Message-ID: <05fd01cfb11c$526cdae0$f74690a0$@gmail.com>

I just realize I had a typo (omission) which made me look pretty ignorant. What I meant to write to Steve was that I did not know one could make valid use of NEGATIVE option button values. Of course I knew one could assign values, but I thought they had to be 0-based. Heh Heh, dust off the old Dunce cap, eh?

 

From: Bill Benson [mailto:bensonforums at gmail.com] 
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

 

Wow Steve, I did not know I could give option buttons values.. This is a  useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz <mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding the option group to the Yes/No field, and setting the Option Value of the option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>


From steve at datamanagementsolutions.biz  Tue Aug  5 22:48:14 2014
From: steve at datamanagementsolutions.biz (Steve Schapel)
Date: Wed, 6 Aug 2014 15:48:14 +1200
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <05fd01cfb11c$526cdae0$f74690a0$@gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p><CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>
	<05fd01cfb11c$526cdae0$f74690a0$@gmail.com>
Message-ID: <9D6C39B88F00431B8233545A51FA9FEE@SteveT540p>

Ah, that makes more sense, Bill!  :)

Actually, Access evaluates any non-zero integer as True.  So I think it 
would work anyway with the option value of the two option buttons as 0 and 
anything else you fancy.

Regards
Steve

-----Original Message----- 
From: Bill Benson
Sent: Wednesday, August 6, 2014 2:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I just realize I had a typo (omission) which made me look pretty ignorant. 
What I meant to write to Steve was that I did not know one could make valid 
use of NEGATIVE option button values. Of course I knew one could assign 
values, but I thought they had to be 0-based. Heh Heh, dust off the old 
Dunce cap, eh?



From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field



Wow Steve, I did not know I could give option buttons values.. This is a 
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz 
<mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding the 
> option group to the Yes/No field, and setting the Option Value of the 
> option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 


From bensonforums at gmail.com  Tue Aug  5 23:30:35 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 6 Aug 2014 00:30:35 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <9D6C39B88F00431B8233545A51FA9FEE@SteveT540p>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p><CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>	<05fd01cfb11c$526cdae0$f74690a0$@gmail.com>
	<9D6C39B88F00431B8233545A51FA9FEE@SteveT540p>
Message-ID: <062001cfb12f$2af592f0$80e0b8d0$@gmail.com>

I think it is also worth pointing out a corollary, that in a Yes/No field,
Access converts any non-zero integer update to -1. That is easily
demonstrated by these two steps conducted in sequence.

	1. Update Drivers Set Inactive = -5 Where ID = 1 '[executes with no
error]
	2. Select CLNG(Inactive) From Drivers Where ID = 1 '[result is -1]

It is intuitive to most good programmers, no doubt, that Access
force-converts non-zero integers to a Boolean value of -1, but I confess at
times the silent conversion confounds me, and I think it would be better for
Access to throw a runtime error upon query execution.

So I totally agree with you that as long as I have a caption or label saying
"Active" next to the option button that has value 0, in the option group
that is bound to the field named Inactive, then I can give the other option
button any non-zero integer value I care to, however the very first time
that control is set to NOT FALSE via reading information from the table, the
value will become -1, regardless what I might think I can cleverly test for
/ set via the interface. 

So I think it is better practice to make the option button with a caption or
label = "INACTIVE" have the option value of -1.

Does that make any sense?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Tuesday, August 05, 2014 11:48 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Ah, that makes more sense, Bill!  :)

Actually, Access evaluates any non-zero integer as True.  So I think it
would work anyway with the option value of the two option buttons as 0 and
anything else you fancy.

Regards
Steve

-----Original Message-----
From: Bill Benson
Sent: Wednesday, August 6, 2014 2:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I just realize I had a typo (omission) which made me look pretty ignorant. 
What I meant to write to Steve was that I did not know one could make valid
use of NEGATIVE option button values. Of course I knew one could assign
values, but I thought they had to be 0-based. Heh Heh, dust off the old
Dunce cap, eh?



From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field



Wow Steve, I did not know I could give option buttons values.. This is a
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz
<mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding 
> the option group to the Yes/No field, and setting the Option Value of 
> the option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Tue Aug  5 23:37:08 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 6 Aug 2014 00:37:08 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <062001cfb12f$2af592f0$80e0b8d0$@gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p><CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>	<05fd01cfb11c$526cdae0$f74690a0$@gmail.com>
	<9D6C39B88F00431B8233545A51FA9FEE@SteveT540p>
	<062001cfb12f$2af592f0$80e0b8d0$@gmail.com>
Message-ID: <062501cfb130$1511fa40$3f35eec0$@gmail.com>

I have, in fact, just proved that setting to anything other than -1 DOES NOT
WORK. I opened the form on a record where that value was TRUE, and the
option button had a value of 5 in my test, and neither option button was
filled. When I changed the option control to have a value of -1 in design
view, then reloaded the form, that control was filled in.

See Steve, it does not pay to try to be too clever.

;-)

-----Original Message-----
From: Bill Benson [mailto:bensonforums at gmail.com] 
Sent: Wednesday, August 06, 2014 12:31 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Creating default false in yes/no field

I think it is also worth pointing out a corollary, that in a Yes/No field,
Access converts any non-zero integer update to -1. That is easily
demonstrated by these two steps conducted in sequence.

	1. Update Drivers Set Inactive = -5 Where ID = 1 '[executes with no
error]
	2. Select CLNG(Inactive) From Drivers Where ID = 1 '[result is -1]

It is intuitive to most good programmers, no doubt, that Access
force-converts non-zero integers to a Boolean value of -1, but I confess at
times the silent conversion confounds me, and I think it would be better for
Access to throw a runtime error upon query execution.

So I totally agree with you that as long as I have a caption or label saying
"Active" next to the option button that has value 0, in the option group
that is bound to the field named Inactive, then I can give the other option
button any non-zero integer value I care to, however the very first time
that control is set to NOT FALSE via reading information from the table, the
value will become -1, regardless what I might think I can cleverly test for
/ set via the interface. 

So I think it is better practice to make the option button with a caption or
label = "INACTIVE" have the option value of -1.

Does that make any sense?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Tuesday, August 05, 2014 11:48 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Ah, that makes more sense, Bill!  :)

Actually, Access evaluates any non-zero integer as True.  So I think it
would work anyway with the option value of the two option buttons as 0 and
anything else you fancy.

Regards
Steve

-----Original Message-----
From: Bill Benson
Sent: Wednesday, August 6, 2014 2:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I just realize I had a typo (omission) which made me look pretty ignorant. 
What I meant to write to Steve was that I did not know one could make valid
use of NEGATIVE option button values. Of course I knew one could assign
values, but I thought they had to be 0-based. Heh Heh, dust off the old
Dunce cap, eh?



From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field



Wow Steve, I did not know I could give option buttons values.. This is a
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz
<mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding 
> the option group to the Yes/No field, and setting the Option Value of 
> the option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From steve at datamanagementsolutions.biz  Wed Aug  6 03:48:49 2014
From: steve at datamanagementsolutions.biz (Steve Schapel)
Date: Wed, 6 Aug 2014 20:48:49 +1200
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <062501cfb130$1511fa40$3f35eec0$@gmail.com>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p><CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>	<05fd01cfb11c$526cdae0$f74690a0$@gmail.com><9D6C39B88F00431B8233545A51FA9FEE@SteveT540p><062001cfb12f$2af592f0$80e0b8d0$@gmail.com>
	<062501cfb130$1511fa40$3f35eec0$@gmail.com>
Message-ID: <1C4049DB099D400FB024093283EF3A89@SteveT540p>

Thanks a lot for checking it, Bill.  And I agree entirely.  I apologise, I 
shouldn't have idly thrown an idea in, which in practice I would never 
actually do anyway, without thinking it through.

Regards
Steve

-----Original Message----- 
From: Bill Benson
Sent: Wednesday, August 6, 2014 4:37 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I have, in fact, just proved that setting to anything other than -1 DOES NOT
WORK. I opened the form on a record where that value was TRUE, and the
option button had a value of 5 in my test, and neither option button was
filled. When I changed the option control to have a value of -1 in design
view, then reloaded the form, that control was filled in.

See Steve, it does not pay to try to be too clever.

;-)

-----Original Message-----
From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Wednesday, August 06, 2014 12:31 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Creating default false in yes/no field

I think it is also worth pointing out a corollary, that in a Yes/No field,
Access converts any non-zero integer update to -1. That is easily
demonstrated by these two steps conducted in sequence.

1. Update Drivers Set Inactive = -5 Where ID = 1 '[executes with no
error]
2. Select CLNG(Inactive) From Drivers Where ID = 1 '[result is -1]

It is intuitive to most good programmers, no doubt, that Access
force-converts non-zero integers to a Boolean value of -1, but I confess at
times the silent conversion confounds me, and I think it would be better for
Access to throw a runtime error upon query execution.

So I totally agree with you that as long as I have a caption or label saying
"Active" next to the option button that has value 0, in the option group
that is bound to the field named Inactive, then I can give the other option
button any non-zero integer value I care to, however the very first time
that control is set to NOT FALSE via reading information from the table, the
value will become -1, regardless what I might think I can cleverly test for
/ set via the interface.

So I think it is better practice to make the option button with a caption or
label = "INACTIVE" have the option value of -1.

Does that make any sense?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Tuesday, August 05, 2014 11:48 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Ah, that makes more sense, Bill!  :)

Actually, Access evaluates any non-zero integer as True.  So I think it
would work anyway with the option value of the two option buttons as 0 and
anything else you fancy.

Regards
Steve

-----Original Message-----
From: Bill Benson
Sent: Wednesday, August 6, 2014 2:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I just realize I had a typo (omission) which made me look pretty ignorant.
What I meant to write to Steve was that I did not know one could make valid
use of NEGATIVE option button values. Of course I knew one could assign
values, but I thought they had to be 0-based. Heh Heh, dust off the old
Dunce cap, eh?



From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field



Wow Steve, I did not know I could give option buttons values.. This is a
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz
<mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding
> the option group to the Yes/No field, and setting the Option Value of
> the option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 


From bensonforums at gmail.com  Wed Aug  6 04:31:37 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 6 Aug 2014 05:31:37 -0400
Subject: [AccessD] Creating default false in yes/no field
In-Reply-To: <1C4049DB099D400FB024093283EF3A89@SteveT540p>
References: <A67D7A698477462F84A1F299EEEA76E6@HAL9007>	<BLU176-DS2BA4D2DD40705D4D39BC5F6E60@phx.gbl>	<A841E2A287874219ACCF46E3DA2107D3@HAL9007>	<CAH+Met9cV=vWFB-2WxLzhLB6LT+W6kPhSFacbbv-O3=OL30QZQ@mail.gmail.com>	<CE411ED5C0304B9CA6E27DB33F092DAD@HAL9007>	<CAH+Met87QPP=B4p7icq-=g1Pu0JMjXvpZ_5qfjQwmi1-5T0tWg@mail.gmail.com>	<F188DA66489C46A7AB8E012DFC5A8C37@HAL9007>	<CAH+Met_Yxp5EiiB=aM8eV1_5oSynYFFgNCdDtmRJvSEu7Wvgvw@mail.gmail.com>	<106108AE4DE54288BF486187FD91070D@HAL9007>	<007601cfadf1$8bcc4f60$a364ee20$@gmail.com>	<211E2C8B32234B8387A7F01494F407E7@SteveT540p><CAJLzs_18QJgpGamjae0e2AzPcc2e2vTWQ0yQVs31mL0VV=SqyQ@mail.gmail.com>	<05fd01cfb11c$526cdae0$f74690a0$@gmail.com><9D6C39B88F00431B8233545A51FA9FEE@SteveT540p><062001cfb12f$2af592f0$80e0b8d0$@gmail.com>	<062501cfb130$1511fa40$3f35eec0$@gmail.com>
	<1C4049DB099D400FB024093283EF3A89@SteveT540p>
Message-ID: <067d01cfb159$3925fbb0$ab71f310$@gmail.com>

>> I shouldn't have idly thrown an idea in

I am glad you did, it caused me to learn something for myself.

Long Live AccessD!
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Wednesday, August 06, 2014 4:49 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Thanks a lot for checking it, Bill.  And I agree entirely.  I apologise, I
shouldn't have idly thrown an idea in, which in practice I would never
actually do anyway, without thinking it through.

Regards
Steve

-----Original Message-----
From: Bill Benson
Sent: Wednesday, August 6, 2014 4:37 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I have, in fact, just proved that setting to anything other than -1 DOES NOT
WORK. I opened the form on a record where that value was TRUE, and the
option button had a value of 5 in my test, and neither option button was
filled. When I changed the option control to have a value of -1 in design
view, then reloaded the form, that control was filled in.

See Steve, it does not pay to try to be too clever.

;-)

-----Original Message-----
From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Wednesday, August 06, 2014 12:31 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Creating default false in yes/no field

I think it is also worth pointing out a corollary, that in a Yes/No field,
Access converts any non-zero integer update to -1. That is easily
demonstrated by these two steps conducted in sequence.

1. Update Drivers Set Inactive = -5 Where ID = 1 '[executes with no error]
2. Select CLNG(Inactive) From Drivers Where ID = 1 '[result is -1]

It is intuitive to most good programmers, no doubt, that Access
force-converts non-zero integers to a Boolean value of -1, but I confess at
times the silent conversion confounds me, and I think it would be better for
Access to throw a runtime error upon query execution.

So I totally agree with you that as long as I have a caption or label saying
"Active" next to the option button that has value 0, in the option group
that is bound to the field named Inactive, then I can give the other option
button any non-zero integer value I care to, however the very first time
that control is set to NOT FALSE via reading information from the table, the
value will become -1, regardless what I might think I can cleverly test for
/ set via the interface.

So I think it is better practice to make the option button with a caption or
label = "INACTIVE" have the option value of -1.

Does that make any sense?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Tuesday, August 05, 2014 11:48 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field

Ah, that makes more sense, Bill!  :)

Actually, Access evaluates any non-zero integer as True.  So I think it
would work anyway with the option value of the two option buttons as 0 and
anything else you fancy.

Regards
Steve

-----Original Message-----
From: Bill Benson
Sent: Wednesday, August 6, 2014 2:15 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Creating default false in yes/no field

I just realize I had a typo (omission) which made me look pretty ignorant.
What I meant to write to Steve was that I did not know one could make valid
use of NEGATIVE option button values. Of course I knew one could assign
values, but I thought they had to be 0-based. Heh Heh, dust off the old
Dunce cap, eh?



From: Bill Benson [mailto:bensonforums at gmail.com]
Sent: Saturday, August 02, 2014 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Creating default false in yes/no field



Wow Steve, I did not know I could give option buttons values.. This is a
useful trick you have given!

Very clever!

-Bill
On Aug 2, 2014 4:13 PM, "Steve Schapel" <steve at datamanagementsolutions.biz
<mailto:steve at datamanagementsolutions.biz> > wrote:
>
> Bill
>
> You could have saved yourself a bit of trouble here by simply binding 
> the option group to the Yes/No field, and setting the Option Value of 
> the option buttons to -1 and 0.
>
> No hidden control, no code.
>
> Regards
> Steve
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From fuller.artful at gmail.com  Fri Aug  8 11:53:28 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 8 Aug 2014 12:53:28 -0400
Subject: [AccessD] Looking for input from someone familiar with political
 campains in the US
Message-ID: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>

The subject pretty much says it. I'm working on an app for smart phones,
tablets and browsers (not written in Access, the app, that is, but the
prototype was written in Access). It has two "faces"; call them Remote and
HQ. The Remote app is for door-to-door canvassers as well as sign crews and
other remote workers/volunteers. The HQ app is for the home office and does
considerably more than the Remote, such as print daily lists for volunteers
and so on.

Since the US election system is quite different than the Canadian system.
I'm familiar with how the electoral system works in the US; that's not the
info I'm after. I'm looking for input from someone(s) who has actually
worked on a campaign or two.

Any volunteers?

-- 
Arthur

From bensonforums at gmail.com  Fri Aug  8 11:57:50 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 8 Aug 2014 12:57:50 -0400
Subject: [AccessD] Looking for input from someone familiar with
	political campains in the US
In-Reply-To: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>
References: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>
Message-ID: <044401cfb329$e4a78a90$adf69fb0$@gmail.com>

"skins"
Not me though.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Friday, August 08, 2014 12:53 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Looking for input from someone familiar with political
campains in the US

The subject pretty much says it. I'm working on an app for smart phones,
tablets and browsers (not written in Access, the app, that is, but the
prototype was written in Access). It has two "faces"; call them Remote and
HQ. The Remote app is for door-to-door canvassers as well as sign crews and
other remote workers/volunteers. The HQ app is for the home office and does
considerably more than the Remote, such as print daily lists for volunteers
and so on.

Since the US election system is quite different than the Canadian system.
I'm familiar with how the electoral system works in the US; that's not the
info I'm after. I'm looking for input from someone(s) who has actually
worked on a campaign or two.

Any volunteers?

--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From accessd at gfconsultants.com  Fri Aug  8 13:13:07 2014
From: accessd at gfconsultants.com (Reuben Cummings)
Date: Fri, 8 Aug 2014 14:13:07 -0400
Subject: [AccessD] Looking for input from someone familiar with
	political campains in the US
In-Reply-To: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>
References: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>
Message-ID: <000f01cfb334$68b72ca0$3a2585e0$@com>

I'm currently treasurer for a campaign for US Rep.

Reuben Cummings
GFC, LLC
812.523.1017

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Friday, August 08, 2014 12:53 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Looking for input from someone familiar with political
campains in the US

The subject pretty much says it. I'm working on an app for smart phones,
tablets and browsers (not written in Access, the app, that is, but the
prototype was written in Access). It has two "faces"; call them Remote and
HQ. The Remote app is for door-to-door canvassers as well as sign crews and
other remote workers/volunteers. The HQ app is for the home office and does
considerably more than the Remote, such as print daily lists for volunteers
and so on.

Since the US election system is quite different than the Canadian system.
I'm familiar with how the electoral system works in the US; that's not the
info I'm after. I'm looking for input from someone(s) who has actually
worked on a campaign or two.

Any volunteers?

--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





From newsgrps at dalyn.co.nz  Sun Aug 10 22:23:39 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Mon, 11 Aug 2014 15:23:39 +1200
Subject: [AccessD] Field linked to different tables
Message-ID: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>

Hi Listers,

 

I am looking for some data structure advice.  I will use a simple example
but the real world application will be more complicated.

 

I have a Notes table.  The Notes table fields include WhoAbout,
LinkRecordID.

 

WhoAbout could be Client, Staff member, or Company. 

LinkRecordID is the ID from the Client, Staff member, or Company table
depending on what was selected in the WhoAbout field.

 

The records from the Notes table will be displayed in a continuous form
showing WhoAbout and the name from the corresponding table for the record
selected in LinkRecordID.

 

The Linkrecord field on the form is a combobox with a union of the records
from the three tables.  Data from all three tables are needed because it is
a continuous form and I don't want to change the recordsource for each
current row as this would show incorrect data in other rows.

 

Immediate problem: Even though I could put code in place to ensure that the
record selected is of the same type as the WhoAbout field the correct row
may not show if it has the same ID as another record from one of the other
tables. 

 

Question:  Has anyone else come across this problem and what might be the
solution?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

 

 


From gustav at cactus.dk  Mon Aug 11 02:59:27 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Mon, 11 Aug 2014 07:59:27 +0000
Subject: [AccessD] Field linked to different tables
Message-ID: <2447267f455444ec9254d4758c681617@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi David

You'll need an WhoAboutID to distinguish the normal Ids from the three tables.

For example, instead of a union of the three tables, create three queries like:

Select 1 As WhoAboutID, * From tblClient
Select 2 As WhoAboutID, * From tblStaff
Select 3 As WhoAboutID, * From tblCompany

then union these, and either use the compound id of WhoAboutID and ID or create a single text id:

[ID] & ";" & [WhoAboutID] As UnionID

for your combobox. When selected, you can use Split to split the UnionID into WhoAboutID and ID.

/gustav


-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af David Emerson
Sendt: 11. august 2014 05:24
Til: AccessD
Emne: [AccessD] Field linked to different tables

Hi Listers,

 

I am looking for some data structure advice.  I will use a simple example but the real world application will be more complicated.

 

I have a Notes table.  The Notes table fields include WhoAbout, LinkRecordID.

 

WhoAbout could be Client, Staff member, or Company. 

LinkRecordID is the ID from the Client, Staff member, or Company table depending on what was selected in the WhoAbout field.

 

The records from the Notes table will be displayed in a continuous form showing WhoAbout and the name from the corresponding table for the record selected in LinkRecordID.

 

The Linkrecord field on the form is a combobox with a union of the records from the three tables.  Data from all three tables are needed because it is a continuous form and I don't want to change the recordsource for each current row as this would show incorrect data in other rows.

 

Immediate problem: Even though I could put code in place to ensure that the record selected is of the same type as the WhoAbout field the correct row may not show if it has the same ID as another record from one of the other tables. 

 

Question:  Has anyone else come across this problem and what might be the solution?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand


From newsgrps at dalyn.co.nz  Mon Aug 11 04:05:04 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Mon, 11 Aug 2014 21:05:04 +1200
Subject: [AccessD] Field linked to different tables
In-Reply-To: <2447267f455444ec9254d4758c681617@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <2447267f455444ec9254d4758c681617@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <006101cfb543$57f935a0$07eba0e0$@dalyn.co.nz>

Thanks Gustav,  I was coming to the same conclusion.  Appreciate your reply.

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Monday, 11 August 2014 7:59 p.m.
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

Hi David

You'll need an WhoAboutID to distinguish the normal Ids from the three
tables.

For example, instead of a union of the three tables, create three queries
like:

Select 1 As WhoAboutID, * From tblClient Select 2 As WhoAboutID, * From
tblStaff Select 3 As WhoAboutID, * From tblCompany

then union these, and either use the compound id of WhoAboutID and ID or
create a single text id:

[ID] & ";" & [WhoAboutID] As UnionID

for your combobox. When selected, you can use Split to split the UnionID
into WhoAboutID and ID.

/gustav


-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] P? vegne af David Emerson
Sendt: 11. august 2014 05:24
Til: AccessD
Emne: [AccessD] Field linked to different tables

Hi Listers,

 

I am looking for some data structure advice.  I will use a simple example
but the real world application will be more complicated.

 

I have a Notes table.  The Notes table fields include WhoAbout,
LinkRecordID.

 

WhoAbout could be Client, Staff member, or Company. 

LinkRecordID is the ID from the Client, Staff member, or Company table
depending on what was selected in the WhoAbout field.

 

The records from the Notes table will be displayed in a continuous form
showing WhoAbout and the name from the corresponding table for the record
selected in LinkRecordID.

 

The Linkrecord field on the form is a combobox with a union of the records
from the three tables.  Data from all three tables are needed because it is
a continuous form and I don't want to change the recordsource for each
current row as this would show incorrect data in other rows.

 

Immediate problem: Even though I could put code in place to ensure that the
record selected is of the same type as the WhoAbout field the correct row
may not show if it has the same ID as another record from one of the other
tables. 

 

Question:  Has anyone else come across this problem and what might be the
solution?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From fuller.artful at gmail.com  Mon Aug 11 08:32:10 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 11 Aug 2014 09:32:10 -0400
Subject: [AccessD] Looking for input from someone familiar with
 political campains in the US
In-Reply-To: <000f01cfb334$68b72ca0$3a2585e0$@com>
References: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>
	<000f01cfb334$68b72ca0$3a2585e0$@com>
Message-ID: <CAEPJO1iPqL0nLgUs2NYttwvXbo4jOu949_fX_ZYXjHz9trynrw@mail.gmail.com>

Reuben,

Thanks for replying. Given the "nuts-and-bolts" nature of the kind of input
I'm after, perhaps it's best we take it off-list, so as not to bore the
others with the nuts and bolts of political campaigns.

Arthur


On Fri, Aug 8, 2014 at 2:13 PM, Reuben Cummings <accessd at gfconsultants.com>
wrote:

> I'm currently treasurer for a campaign for US Rep.
>
> Reuben Cummings
> GFC, LLC
> 812.523.1017
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Friday, August 08, 2014 12:53 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Looking for input from someone familiar with political
> campains in the US
>
> The subject pretty much says it. I'm working on an app for smart phones,
> tablets and browsers (not written in Access, the app, that is, but the
> prototype was written in Access). It has two "faces"; call them Remote and
> HQ. The Remote app is for door-to-door canvassers as well as sign crews and
> other remote workers/volunteers. The HQ app is for the home office and does
> considerably more than the Remote, such as print daily lists for volunteers
> and so on.
>
> Since the US election system is quite different than the Canadian system.
> I'm familiar with how the electoral system works in the US; that's not the
> info I'm after. I'm looking for input from someone(s) who has actually
> worked on a campaign or two.
>
> Any volunteers?
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur

From accessd at gfconsultants.com  Mon Aug 11 09:03:21 2014
From: accessd at gfconsultants.com (Reuben Cummings)
Date: Mon, 11 Aug 2014 10:03:21 -0400
Subject: [AccessD] Looking for input from someone familiar with
	political campains in the US
In-Reply-To: <CAEPJO1iPqL0nLgUs2NYttwvXbo4jOu949_fX_ZYXjHz9trynrw@mail.gmail.com>
References: <CAEPJO1iorKQ1fvuQBp12VDyHs2ZUhq=OOa8aTCCTsGsJV+cHDA@mail.gmail.com>	<000f01cfb334$68b72ca0$3a2585e0$@com>
	<CAEPJO1iPqL0nLgUs2NYttwvXbo4jOu949_fX_ZYXjHz9trynrw@mail.gmail.com>
Message-ID: <00e801cfb56d$02f4e3e0$08deaba0$@com>

I agree. Not sure I'm of much value, but email me at
reuben at gfconsultants.com
I'm sure I can get other staffers to give some input as well.

Reuben Cummings
GFC, LLC
812.523.1017

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Monday, August 11, 2014 9:32 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Looking for input from someone familiar with
political campains in the US

Reuben,

Thanks for replying. Given the "nuts-and-bolts" nature of the kind of input
I'm after, perhaps it's best we take it off-list, so as not to bore the
others with the nuts and bolts of political campaigns.

Arthur


On Fri, Aug 8, 2014 at 2:13 PM, Reuben Cummings <accessd at gfconsultants.com>
wrote:

> I'm currently treasurer for a campaign for US Rep.
>
> Reuben Cummings
> GFC, LLC
> 812.523.1017
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur 
> Fuller
> Sent: Friday, August 08, 2014 12:53 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Looking for input from someone familiar with 
> political campains in the US
>
> The subject pretty much says it. I'm working on an app for smart 
> phones, tablets and browsers (not written in Access, the app, that is, 
> but the prototype was written in Access). It has two "faces"; call 
> them Remote and HQ. The Remote app is for door-to-door canvassers as 
> well as sign crews and other remote workers/volunteers. The HQ app is 
> for the home office and does considerably more than the Remote, such 
> as print daily lists for volunteers and so on.
>
> Since the US election system is quite different than the Canadian system.
> I'm familiar with how the electoral system works in the US; that's not 
> the info I'm after. I'm looking for input from someone(s) who has 
> actually worked on a campaign or two.
>
> Any volunteers?
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





From stuart at lexacorp.com.pg  Mon Aug 11 19:06:03 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Tue, 12 Aug 2014 10:06:03 +1000
Subject: [AccessD] Field linked to different tables
In-Reply-To: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
Message-ID: <53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>

How about another field in the Notes table "WhoAboutType"  (1 for Client, 2 for Staff, 3 for 
Company or whatever) 

Then 
Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm tblClients
UNION
Select 2 as WAType, StaffPK as PK, StaffName as EntityName from tblStaff
UNION
Select 3 as WAType, CompanyPK as PK, CoName as EntityName from tblCompany.


Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)


-- 
Stuart

On 11 Aug 2014 at 15:23, David Emerson wrote:

> Hi Listers,
> 
> 
> 
> I am looking for some data structure advice.  I will use a simple
> example but the real world application will be more complicated.
> 
> 
> 
> I have a Notes table.  The Notes table fields include WhoAbout,
> LinkRecordID.
> 
> 
> 
> WhoAbout could be Client, Staff member, or Company. 
> 
> LinkRecordID is the ID from the Client, Staff member, or Company table
> depending on what was selected in the WhoAbout field.
> 
> 
> 
> The records from the Notes table will be displayed in a continuous
> form showing WhoAbout and the name from the corresponding table for
> the record selected in LinkRecordID.
> 
> 
> 
> The Linkrecord field on the form is a combobox with a union of the
> records from the three tables.  Data from all three tables are needed
> because it is a continuous form and I don't want to change the
> recordsource for each current row as this would show incorrect data in
> other rows.
> 
> 
> 
> Immediate problem: Even though I could put code in place to ensure
> that the record selected is of the same type as the WhoAbout field the
> correct row may not show if it has the same ID as another record from
> one of the other tables. 
> 
> 
> 
> Question:  Has anyone else come across this problem and what might be
> the solution?
> 
> 
> 
> Regards
> 
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
> 
> 
> 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From newsgrps at dalyn.co.nz  Mon Aug 11 19:24:00 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Tue, 12 Aug 2014 12:24:00 +1200
Subject: [AccessD] Field linked to different tables
In-Reply-To: <53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
Message-ID: <004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>

Thanks for the reply Stuart.  This will still have the problem in the
combobox that it may not show the correct selected record if the ID's from
the various tables in the first column double up.

Gustav suggested making a composite key that combines the "WhoAboutType" and
source table ID's so that there will not be any replications.  This will
solve the problem.

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Tuesday, 12 August 2014 12:06 p.m.
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

How about another field in the Notes table "WhoAboutType"  (1 for Client, 2
for Staff, 3 for Company or whatever) 

Then
Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm tblClients
UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from
tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as EntityName
from tblCompany.


Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)


-- 
Stuart

On 11 Aug 2014 at 15:23, David Emerson wrote:

> Hi Listers,
> 
> 
> 
> I am looking for some data structure advice.  I will use a simple
> example but the real world application will be more complicated.
> 
> 
> 
> I have a Notes table.  The Notes table fields include WhoAbout,
> LinkRecordID.
> 
> 
> 
> WhoAbout could be Client, Staff member, or Company. 
> 
> LinkRecordID is the ID from the Client, Staff member, or Company table
> depending on what was selected in the WhoAbout field.
> 
> 
> 
> The records from the Notes table will be displayed in a continuous
> form showing WhoAbout and the name from the corresponding table for
> the record selected in LinkRecordID.
> 
> 
> 
> The Linkrecord field on the form is a combobox with a union of the
> records from the three tables.  Data from all three tables are needed
> because it is a continuous form and I don't want to change the
> recordsource for each current row as this would show incorrect data in
> other rows.
> 
> 
> 
> Immediate problem: Even though I could put code in place to ensure
> that the record selected is of the same type as the WhoAbout field the
> correct row may not show if it has the same ID as another record from
> one of the other tables. 
> 
> 
> 
> Question:  Has anyone else come across this problem and what might be
> the solution?
> 
> 
> 
> Regards
> 
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
> 
> 
> 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From fuller.artful at gmail.com  Tue Aug 12 10:39:07 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 12 Aug 2014 11:39:07 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
	<004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
Message-ID: <CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>

David,

I've had to skin a cat like this a few times in the past, and agree with
Gustav's suggestion. In fact, the experience has caused me, in several
situations, to re-think the whole knee-jerk AutoNumberPK thins that I once
depended on to the exclusion of logic and common sense. (For example, why
give a list of countries an ANPK when there already exists a well-defined
ISO list of countries, each having a unique char code?)

Arthur


On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz> wrote:

> Thanks for the reply Stuart.  This will still have the problem in the
> combobox that it may not show the correct selected record if the ID's from
> the various tables in the first column double up.
>
> Gustav suggested making a composite key that combines the "WhoAboutType"
> and
> source table ID's so that there will not be any replications.  This will
> solve the problem.
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan
> Sent: Tuesday, 12 August 2014 12:06 p.m.
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Field linked to different tables
>
> How about another field in the Notes table "WhoAboutType"  (1 for Client, 2
> for Staff, 3 for Company or whatever)
>
> Then
> Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm tblClients
> UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from
> tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as EntityName
> from tblCompany.
>
>
> Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
>
>
> --
> Stuart
>
> On 11 Aug 2014 at 15:23, David Emerson wrote:
>
> > Hi Listers,
> >
> >
> >
> > I am looking for some data structure advice.  I will use a simple
> > example but the real world application will be more complicated.
> >
> >
> >
> > I have a Notes table.  The Notes table fields include WhoAbout,
> > LinkRecordID.
> >
> >
> >
> > WhoAbout could be Client, Staff member, or Company.
> >
> > LinkRecordID is the ID from the Client, Staff member, or Company table
> > depending on what was selected in the WhoAbout field.
> >
> >
> >
> > The records from the Notes table will be displayed in a continuous
> > form showing WhoAbout and the name from the corresponding table for
> > the record selected in LinkRecordID.
> >
> >
> >
> > The Linkrecord field on the form is a combobox with a union of the
> > records from the three tables.  Data from all three tables are needed
> > because it is a continuous form and I don't want to change the
> > recordsource for each current row as this would show incorrect data in
> > other rows.
> >
> >
> >
> > Immediate problem: Even though I could put code in place to ensure
> > that the record selected is of the same type as the WhoAbout field the
> > correct row may not show if it has the same ID as another record from
> > one of the other tables.
> >
> >
> >
> > Question:  Has anyone else come across this problem and what might be
> > the solution?
> >
> >
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur

From jimdettman at verizon.net  Tue Aug 12 12:14:29 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Tue, 12 Aug 2014 13:14:29 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
	<004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>
Message-ID: <1023F5A39C4E4B71B6EB7006106B5BFC@XPS>

<<why give a list of countries an ANPK when there already exists a
well-defined
ISO list of countries, each having a unique char code>>

 Someone on my side of the fence for a change<g>

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 12, 2014 11:39 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

David,

I've had to skin a cat like this a few times in the past, and agree with
Gustav's suggestion. In fact, the experience has caused me, in several
situations, to re-think the whole knee-jerk AutoNumberPK thins that I once
depended on to the exclusion of logic and common sense. (For example, why
give a list of countries an ANPK when there already exists a well-defined
ISO list of countries, each having a unique char code?)

Arthur


On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz> wrote:

> Thanks for the reply Stuart.  This will still have the problem in the
> combobox that it may not show the correct selected record if the ID's from
> the various tables in the first column double up.
>
> Gustav suggested making a composite key that combines the "WhoAboutType"
> and
> source table ID's so that there will not be any replications.  This will
> solve the problem.
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan
> Sent: Tuesday, 12 August 2014 12:06 p.m.
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Field linked to different tables
>
> How about another field in the Notes table "WhoAboutType"  (1 for Client,
2
> for Staff, 3 for Company or whatever)
>
> Then
> Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
tblClients
> UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from
> tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as EntityName
> from tblCompany.
>
>
> Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
>
>
> --
> Stuart
>
> On 11 Aug 2014 at 15:23, David Emerson wrote:
>
> > Hi Listers,
> >
> >
> >
> > I am looking for some data structure advice.  I will use a simple
> > example but the real world application will be more complicated.
> >
> >
> >
> > I have a Notes table.  The Notes table fields include WhoAbout,
> > LinkRecordID.
> >
> >
> >
> > WhoAbout could be Client, Staff member, or Company.
> >
> > LinkRecordID is the ID from the Client, Staff member, or Company table
> > depending on what was selected in the WhoAbout field.
> >
> >
> >
> > The records from the Notes table will be displayed in a continuous
> > form showing WhoAbout and the name from the corresponding table for
> > the record selected in LinkRecordID.
> >
> >
> >
> > The Linkrecord field on the form is a combobox with a union of the
> > records from the three tables.  Data from all three tables are needed
> > because it is a continuous form and I don't want to change the
> > recordsource for each current row as this would show incorrect data in
> > other rows.
> >
> >
> >
> > Immediate problem: Even though I could put code in place to ensure
> > that the record selected is of the same type as the WhoAbout field the
> > correct row may not show if it has the same ID as another record from
> > one of the other tables.
> >
> >
> >
> > Question:  Has anyone else come across this problem and what might be
> > the solution?
> >
> >
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jackandpat.d at gmail.com  Tue Aug 12 16:00:21 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Tue, 12 Aug 2014 17:00:21 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
	<004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>
	<1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
Message-ID: <CAKvidAtVLMoMatsKYfJG3T-Jivsg+=S52eevy8=0q6J5tnVJnA@mail.gmail.com>

I recall when Canada created a new area Nunavut (NU), then changed the
abbreviation for Quebec from PQ to QC, and Newfoundland to Newfoundland and
Labrador and the abbreviation from NF to NL
Just saying that some codes are just not as  "forever" as you may think.


Just for reference, here is a brief item from ISO 3166
Country Codes - ISO 3166 What is ISO 3166?

ISO 3166 is the International Standard for country codes and codes for
their subdivisions.

The purpose of ISO 3166 is to define internationally recognised codes of
letters and/or numbers that we can use when we refer to countries and
subdivisions. However, it does not define the names of countries ? this
information comes from United Nations sources (Terminology Bulletin Country
Names and the Country and Region Codes for Statistical Use maintained by
the United Nations Statistics Divisions).

Using codes saves time and avoids errors as instead of using a country's
name (which will change depending on the language being used) we can use a
combination of letters and/or numbers that are understood all over the
world.

For example, all national postal organizations throughout the world
exchange international mail in containers identified with the relevant
country code. Internet domain name systems use the codes to define top
level domain names such as '.fr' for France, '.au' for Australia. In
addition, in machine readable passports, the codes are used to determine
the nationality of the user and when we send money from one bank to another
the country codes are a way to identify where the bank is based.
What is included in ISO 3166?

ISO 3166 has three parts: codes for countries, codes for subdivisions and
formerly used codes (codes that were once used to describe countries but
are no longer in use).

The *country codes* can be represented either as a two-letter code
(alpha-2) which is recommended as the general purpose code, a three-letter
code (alpha-3) which is more closely related to the country name and a
three digit numeric code (numeric -3) which can be useful if you need to
avoid using Latin script.
.


On Tue, Aug 12, 2014 at 1:14 PM, Jim Dettman <jimdettman at verizon.net> wrote:

> <<why give a list of countries an ANPK when there already exists a
> well-defined
> ISO list of countries, each having a unique char code>>
>
>  Someone on my side of the fence for a change<g>
>
> Jim.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 12, 2014 11:39 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Field linked to different tables
>
> David,
>
> I've had to skin a cat like this a few times in the past, and agree with
> Gustav's suggestion. In fact, the experience has caused me, in several
> situations, to re-think the whole knee-jerk AutoNumberPK thins that I once
> depended on to the exclusion of logic and common sense. (For example, why
> give a list of countries an ANPK when there already exists a well-defined
> ISO list of countries, each having a unique char code?)
>
> Arthur
>
>
> On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz>
> wrote:
>
> > Thanks for the reply Stuart.  This will still have the problem in the
> > combobox that it may not show the correct selected record if the ID's
> from
> > the various tables in the first column double up.
> >
> > Gustav suggested making a composite key that combines the "WhoAboutType"
> > and
> > source table ID's so that there will not be any replications.  This will
> > solve the problem.
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan
> > Sent: Tuesday, 12 August 2014 12:06 p.m.
> > To: Access Developers discussion and problem solving
> > Subject: Re: [AccessD] Field linked to different tables
> >
> > How about another field in the Notes table "WhoAboutType"  (1 for Client,
> 2
> > for Staff, 3 for Company or whatever)
> >
> > Then
> > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> tblClients
> > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from
> > tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as EntityName
> > from tblCompany.
> >
> >
> > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> >
> >
> > --
> > Stuart
> >
> > On 11 Aug 2014 at 15:23, David Emerson wrote:
> >
> > > Hi Listers,
> > >
> > >
> > >
> > > I am looking for some data structure advice.  I will use a simple
> > > example but the real world application will be more complicated.
> > >
> > >
> > >
> > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > LinkRecordID.
> > >
> > >
> > >
> > > WhoAbout could be Client, Staff member, or Company.
> > >
> > > LinkRecordID is the ID from the Client, Staff member, or Company table
> > > depending on what was selected in the WhoAbout field.
> > >
> > >
> > >
> > > The records from the Notes table will be displayed in a continuous
> > > form showing WhoAbout and the name from the corresponding table for
> > > the record selected in LinkRecordID.
> > >
> > >
> > >
> > > The Linkrecord field on the form is a combobox with a union of the
> > > records from the three tables.  Data from all three tables are needed
> > > because it is a continuous form and I don't want to change the
> > > recordsource for each current row as this would show incorrect data in
> > > other rows.
> > >
> > >
> > >
> > > Immediate problem: Even though I could put code in place to ensure
> > > that the record selected is of the same type as the WhoAbout field the
> > > correct row may not show if it has the same ID as another record from
> > > one of the other tables.
> > >
> > >
> > >
> > > Question:  Has anyone else come across this problem and what might be
> > > the solution?
> > >
> > >
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From Lambert.Heenan at aig.com  Tue Aug 12 16:01:02 2014
From: Lambert.Heenan at aig.com (Heenan, Lambert)
Date: Tue, 12 Aug 2014 21:01:02 +0000
Subject: [AccessD] Field linked to different tables
In-Reply-To: <1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
	<004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>
	<1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
Message-ID: <D2D5A45EB26EC34F8199762DC40FFAA8042990@PWGSMSLIVMBS04.mail.aig.net>

Perhaps because standards are designed by people and people sometime change their minds? For instance there is a standard out there: ICD9 which is a system of codifying medical diagnosis. But now "they" have come up with ICD10 to replace it, and just for fun there is "No Clear Mapping Between ICD-9-CM and ICD-10-CM Code Sets"

:-)

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Tuesday, August 12, 2014 1:14 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Field linked to different tables

<<why give a list of countries an ANPK when there already exists a well-defined ISO list of countries, each having a unique char code>>

 Someone on my side of the fence for a change<g>

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 12, 2014 11:39 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

David,

I've had to skin a cat like this a few times in the past, and agree with Gustav's suggestion. In fact, the experience has caused me, in several situations, to re-think the whole knee-jerk AutoNumberPK thins that I once depended on to the exclusion of logic and common sense. (For example, why give a list of countries an ANPK when there already exists a well-defined ISO list of countries, each having a unique char code?)

Arthur


On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz> wrote:

> Thanks for the reply Stuart.  This will still have the problem in the 
> combobox that it may not show the correct selected record if the ID's 
> from the various tables in the first column double up.
>
> Gustav suggested making a composite key that combines the "WhoAboutType"
> and
> source table ID's so that there will not be any replications.  This 
> will solve the problem.
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart 
> McLachlan
> Sent: Tuesday, 12 August 2014 12:06 p.m.
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Field linked to different tables
>
> How about another field in the Notes table "WhoAboutType"  (1 for 
> Client,
2
> for Staff, 3 for Company or whatever)
>
> Then
> Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
tblClients
> UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from 
> tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as 
> EntityName from tblCompany.
>
>
> Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
>
>
> --
> Stuart
>
> On 11 Aug 2014 at 15:23, David Emerson wrote:
>
> > Hi Listers,
> >
> >
> >
> > I am looking for some data structure advice.  I will use a simple 
> > example but the real world application will be more complicated.
> >
> >
> >
> > I have a Notes table.  The Notes table fields include WhoAbout, 
> > LinkRecordID.
> >
> >
> >
> > WhoAbout could be Client, Staff member, or Company.
> >
> > LinkRecordID is the ID from the Client, Staff member, or Company 
> > table depending on what was selected in the WhoAbout field.
> >
> >
> >
> > The records from the Notes table will be displayed in a continuous 
> > form showing WhoAbout and the name from the corresponding table for 
> > the record selected in LinkRecordID.
> >
> >
> >
> > The Linkrecord field on the form is a combobox with a union of the 
> > records from the three tables.  Data from all three tables are 
> > needed because it is a continuous form and I don't want to change 
> > the recordsource for each current row as this would show incorrect 
> > data in other rows.
> >
> >
> >
> > Immediate problem: Even though I could put code in place to ensure 
> > that the record selected is of the same type as the WhoAbout field 
> > the correct row may not show if it has the same ID as another record 
> > from one of the other tables.
> >
> >
> >
> > Question:  Has anyone else come across this problem and what might 
> > be the solution?
> >
> >
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jimdettman at verizon.net  Tue Aug 12 16:14:31 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Tue, 12 Aug 2014 17:14:31 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <CAKvidAtVLMoMatsKYfJG3T-Jivsg+=S52eevy8=0q6J5tnVJnA@mail.gmail.com>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>
	<53E95A6B.14020.C3DAB83C@stuart.lexacorp.com.pg>
	<004401cfb5c3$b6d0a150$2471e3f0$@dalyn.co.nz>
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>
	<1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
	<CAKvidAtVLMoMatsKYfJG3T-Jivsg+=S52eevy8=0q6J5tnVJnA@mail.gmail.com>
Message-ID: <8A33B84042624D31A1538195A2769EB7@XPS>

<<Just saying that some codes are just not as  "forever" as you may think.>>

 True enough, but there is nothing in relational design that says a primary
key cannot change.   That myth grew up out of data warehousing requirements
and has since been carried forward into relational designs.  AN/Identity
keys are a convenience used to achieve performance and sometimes, it's plain
silly to include one just for the sake of having one.

Jim.  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
Sent: Tuesday, August 12, 2014 05:00 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

I recall when Canada created a new area Nunavut (NU), then changed the
abbreviation for Quebec from PQ to QC, and Newfoundland to Newfoundland and
Labrador and the abbreviation from NF to NL
Just saying that some codes are just not as  "forever" as you may think.


Just for reference, here is a brief item from ISO 3166
Country Codes - ISO 3166 What is ISO 3166?

ISO 3166 is the International Standard for country codes and codes for
their subdivisions.

The purpose of ISO 3166 is to define internationally recognised codes of
letters and/or numbers that we can use when we refer to countries and
subdivisions. However, it does not define the names of countries - this
information comes from United Nations sources (Terminology Bulletin Country
Names and the Country and Region Codes for Statistical Use maintained by
the United Nations Statistics Divisions).

Using codes saves time and avoids errors as instead of using a country's
name (which will change depending on the language being used) we can use a
combination of letters and/or numbers that are understood all over the
world.

For example, all national postal organizations throughout the world
exchange international mail in containers identified with the relevant
country code. Internet domain name systems use the codes to define top
level domain names such as '.fr' for France, '.au' for Australia. In
addition, in machine readable passports, the codes are used to determine
the nationality of the user and when we send money from one bank to another
the country codes are a way to identify where the bank is based.
What is included in ISO 3166?

ISO 3166 has three parts: codes for countries, codes for subdivisions and
formerly used codes (codes that were once used to describe countries but
are no longer in use).

The *country codes* can be represented either as a two-letter code
(alpha-2) which is recommended as the general purpose code, a three-letter
code (alpha-3) which is more closely related to the country name and a
three digit numeric code (numeric -3) which can be useful if you need to
avoid using Latin script.
.


On Tue, Aug 12, 2014 at 1:14 PM, Jim Dettman <jimdettman at verizon.net> wrote:

> <<why give a list of countries an ANPK when there already exists a
> well-defined
> ISO list of countries, each having a unique char code>>
>
>  Someone on my side of the fence for a change<g>
>
> Jim.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 12, 2014 11:39 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Field linked to different tables
>
> David,
>
> I've had to skin a cat like this a few times in the past, and agree with
> Gustav's suggestion. In fact, the experience has caused me, in several
> situations, to re-think the whole knee-jerk AutoNumberPK thins that I once
> depended on to the exclusion of logic and common sense. (For example, why
> give a list of countries an ANPK when there already exists a well-defined
> ISO list of countries, each having a unique char code?)
>
> Arthur
>
>
> On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz>
> wrote:
>
> > Thanks for the reply Stuart.  This will still have the problem in the
> > combobox that it may not show the correct selected record if the ID's
> from
> > the various tables in the first column double up.
> >
> > Gustav suggested making a composite key that combines the "WhoAboutType"
> > and
> > source table ID's so that there will not be any replications.  This will
> > solve the problem.
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan
> > Sent: Tuesday, 12 August 2014 12:06 p.m.
> > To: Access Developers discussion and problem solving
> > Subject: Re: [AccessD] Field linked to different tables
> >
> > How about another field in the Notes table "WhoAboutType"  (1 for
Client,
> 2
> > for Staff, 3 for Company or whatever)
> >
> > Then
> > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> tblClients
> > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName from
> > tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as EntityName
> > from tblCompany.
> >
> >
> > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> >
> >
> > --
> > Stuart
> >
> > On 11 Aug 2014 at 15:23, David Emerson wrote:
> >
> > > Hi Listers,
> > >
> > >
> > >
> > > I am looking for some data structure advice.  I will use a simple
> > > example but the real world application will be more complicated.
> > >
> > >
> > >
> > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > LinkRecordID.
> > >
> > >
> > >
> > > WhoAbout could be Client, Staff member, or Company.
> > >
> > > LinkRecordID is the ID from the Client, Staff member, or Company table
> > > depending on what was selected in the WhoAbout field.
> > >
> > >
> > >
> > > The records from the Notes table will be displayed in a continuous
> > > form showing WhoAbout and the name from the corresponding table for
> > > the record selected in LinkRecordID.
> > >
> > >
> > >
> > > The Linkrecord field on the form is a combobox with a union of the
> > > records from the three tables.  Data from all three tables are needed
> > > because it is a continuous form and I don't want to change the
> > > recordsource for each current row as this would show incorrect data in
> > > other rows.
> > >
> > >
> > >
> > > Immediate problem: Even though I could put code in place to ensure
> > > that the record selected is of the same type as the WhoAbout field the
> > > correct row may not show if it has the same ID as another record from
> > > one of the other tables.
> > >
> > >
> > >
> > > Question:  Has anyone else come across this problem and what might be
> > > the solution?
> > >
> > >
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Tue Aug 12 16:48:20 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 13 Aug 2014 07:48:20 +1000
Subject: [AccessD] Field linked to different tables
In-Reply-To: <1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>,
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>,
	<1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
Message-ID: <53EA8BA4.3495.C88302FA@stuart.lexacorp.com.pg>

Because indexing on a Long is more efficient than indexing on a character string?

(It's computationally much faster and uses far less storage).

-- 
Stuart


On 12 Aug 2014 at 13:14, Jim Dettman wrote:

> <<why give a list of countries an ANPK when there already exists a
> well-defined ISO list of countries, each having a unique char code>>
> 
>  Someone on my side of the fence for a change<g>
> 
> Jim. 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller Sent: Tuesday, August 12, 2014 11:39 AM To: Access Developers
> discussion and problem solving Subject: Re: [AccessD] Field linked to
> different tables
> 
> David,
> 
> I've had to skin a cat like this a few times in the past, and agree
> with Gustav's suggestion. In fact, the experience has caused me, in
> several situations, to re-think the whole knee-jerk AutoNumberPK thins
> that I once depended on to the exclusion of logic and common sense.
> (For example, why give a list of countries an ANPK when there already
> exists a well-defined ISO list of countries, each having a unique char
> code?)
> 
> Arthur
> 
> 
> On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz>
> wrote:
> 
> > Thanks for the reply Stuart.  This will still have the problem in
> > the combobox that it may not show the correct selected record if the
> > ID's from the various tables in the first column double up.
> >
> > Gustav suggested making a composite key that combines the
> > "WhoAboutType" and source table ID's so that there will not be any
> > replications.  This will solve the problem.
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan Sent: Tuesday, 12 August 2014 12:06 p.m. To: Access
> > Developers discussion and problem solving Subject: Re: [AccessD]
> > Field linked to different tables
> >
> > How about another field in the Notes table "WhoAboutType"  (1 for
> > Client,
> 2
> > for Staff, 3 for Company or whatever)
> >
> > Then
> > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> tblClients
> > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName
> > from tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as
> > EntityName from tblCompany.
> >
> >
> > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> >
> >
> > --
> > Stuart
> >
> > On 11 Aug 2014 at 15:23, David Emerson wrote:
> >
> > > Hi Listers,
> > >
> > >
> > >
> > > I am looking for some data structure advice.  I will use a simple
> > > example but the real world application will be more complicated.
> > >
> > >
> > >
> > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > LinkRecordID.
> > >
> > >
> > >
> > > WhoAbout could be Client, Staff member, or Company.
> > >
> > > LinkRecordID is the ID from the Client, Staff member, or Company
> > > table depending on what was selected in the WhoAbout field.
> > >
> > >
> > >
> > > The records from the Notes table will be displayed in a continuous
> > > form showing WhoAbout and the name from the corresponding table
> > > for the record selected in LinkRecordID.
> > >
> > >
> > >
> > > The Linkrecord field on the form is a combobox with a union of the
> > > records from the three tables.  Data from all three tables are
> > > needed because it is a continuous form and I don't want to change
> > > the recordsource for each current row as this would show incorrect
> > > data in other rows.
> > >
> > >
> > >
> > > Immediate problem: Even though I could put code in place to ensure
> > > that the record selected is of the same type as the WhoAbout field
> > > the correct row may not show if it has the same ID as another
> > > record from one of the other tables.
> > >
> > >
> > >
> > > Question:  Has anyone else come across this problem and what might
> > > be the solution?
> > >
> > >
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> 
> 
> 
> -- 
> Arthur
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From jimdettman at verizon.net  Tue Aug 12 21:11:37 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Tue, 12 Aug 2014 22:11:37 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <53EA8BA4.3495.C88302FA@stuart.lexacorp.com.pg>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>,
	<CAEPJO1hAt4n1+Yf1=Bx9ojHF4tZdonJ3pqu1GdYO08oMA3Cg1w@mail.gmail.com>,
	<1023F5A39C4E4B71B6EB7006106B5BFC@XPS>
	<53EA8BA4.3495.C88302FA@stuart.lexacorp.com.pg>
Message-ID: <0E13EF2818A84C999F789AA78C3C9909@XPS>


 I think it would depend on the string.  

 Gains in the difference in register operations could be far out weighed by
the gain in index operations.   As a simple example, a long is four bytes,
which means any string key shorter than that would pack more key entries per
index page.   Search operations would be faster as a result

 And that's besides the fact that I'd have one less index on the table to
maintain.

 One place I think it's silly to have a AN as a primary key is a many to
many linking table (assuming it has no additional attributes other than
expressing the relationship between the tables).  You need a compound index
on the two foreign keys no matter what, so why throw an AN on top of that?
  
Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Tuesday, August 12, 2014 05:48 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

Because indexing on a Long is more efficient than indexing on a character
string?

(It's computationally much faster and uses far less storage).

-- 
Stuart


On 12 Aug 2014 at 13:14, Jim Dettman wrote:

> <<why give a list of countries an ANPK when there already exists a
> well-defined ISO list of countries, each having a unique char code>>
> 
>  Someone on my side of the fence for a change<g>
> 
> Jim. 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller Sent: Tuesday, August 12, 2014 11:39 AM To: Access Developers
> discussion and problem solving Subject: Re: [AccessD] Field linked to
> different tables
> 
> David,
> 
> I've had to skin a cat like this a few times in the past, and agree
> with Gustav's suggestion. In fact, the experience has caused me, in
> several situations, to re-think the whole knee-jerk AutoNumberPK thins
> that I once depended on to the exclusion of logic and common sense.
> (For example, why give a list of countries an ANPK when there already
> exists a well-defined ISO list of countries, each having a unique char
> code?)
> 
> Arthur
> 
> 
> On Mon, Aug 11, 2014 at 8:24 PM, David Emerson <newsgrps at dalyn.co.nz>
> wrote:
> 
> > Thanks for the reply Stuart.  This will still have the problem in
> > the combobox that it may not show the correct selected record if the
> > ID's from the various tables in the first column double up.
> >
> > Gustav suggested making a composite key that combines the
> > "WhoAboutType" and source table ID's so that there will not be any
> > replications.  This will solve the problem.
> >
> > Regards
> >
> > David Emerson
> > Dalyn Software Ltd
> > Wellington, New Zealand
> >
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan Sent: Tuesday, 12 August 2014 12:06 p.m. To: Access
> > Developers discussion and problem solving Subject: Re: [AccessD]
> > Field linked to different tables
> >
> > How about another field in the Notes table "WhoAboutType"  (1 for
> > Client,
> 2
> > for Staff, 3 for Company or whatever)
> >
> > Then
> > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> tblClients
> > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName
> > from tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as
> > EntityName from tblCompany.
> >
> >
> > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> >
> >
> > --
> > Stuart
> >
> > On 11 Aug 2014 at 15:23, David Emerson wrote:
> >
> > > Hi Listers,
> > >
> > >
> > >
> > > I am looking for some data structure advice.  I will use a simple
> > > example but the real world application will be more complicated.
> > >
> > >
> > >
> > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > LinkRecordID.
> > >
> > >
> > >
> > > WhoAbout could be Client, Staff member, or Company.
> > >
> > > LinkRecordID is the ID from the Client, Staff member, or Company
> > > table depending on what was selected in the WhoAbout field.
> > >
> > >
> > >
> > > The records from the Notes table will be displayed in a continuous
> > > form showing WhoAbout and the name from the corresponding table
> > > for the record selected in LinkRecordID.
> > >
> > >
> > >
> > > The Linkrecord field on the form is a combobox with a union of the
> > > records from the three tables.  Data from all three tables are
> > > needed because it is a continuous form and I don't want to change
> > > the recordsource for each current row as this would show incorrect
> > > data in other rows.
> > >
> > >
> > >
> > > Immediate problem: Even though I could put code in place to ensure
> > > that the record selected is of the same type as the WhoAbout field
> > > the correct row may not show if it has the same ID as another
> > > record from one of the other tables.
> > >
> > >
> > >
> > > Question:  Has anyone else come across this problem and what might
> > > be the solution?
> > >
> > >
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> 
> 
> 
> -- 
> Arthur
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Tue Aug 12 21:56:41 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 13 Aug 2014 12:56:41 +1000
Subject: [AccessD] Field linked to different tables
In-Reply-To: <0E13EF2818A84C999F789AA78C3C9909@XPS>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>,
	<53EA8BA4.3495.C88302FA@stuart.lexacorp.com.pg>,
	<0E13EF2818A84C999F789AA78C3C9909@XPS>
Message-ID: <53EAD3E9.7971.C99D4DB5@stuart.lexacorp.com.pg>

True, a Long is four bytes.

But the minimum length of a non-Null string is also four bytes.  An initial two bytes to 
storelength of the string, followed by the characters stored as  2 byte WCHARs.

So a four character string actually requires 10 bytes of storage.   Strings take a lot more 
storage than longs. 

As for searching,  It only requires one operation to compare two 32 bit values (i.e. longs).  
String comparisons take orders of magnitude more time to do.

I agree with you totally about link tables.  They are a different matter entirely. If you consider it 
from an Entity/Relationship perspective, unlike a normal data table -  they do not contain 
entity data, only relationship information.  By their nature, they do not require a separate key.

-- 
Stuart


On 12 Aug 2014 at 22:11, Jim Dettman wrote:

> 
>  I think it would depend on the string.  
> 
>  Gains in the difference in register operations could be far out
>  weighed by
> the gain in index operations.   As a simple example, a long is four
> bytes, which means any string key shorter than that would pack more
> key entries per index page.   Search operations would be faster as a
> result
> 
>  And that's besides the fact that I'd have one less index on the table
>  to
> maintain.
> 
>  One place I think it's silly to have a AN as a primary key is a many
>  to
> many linking table (assuming it has no additional attributes other
> than expressing the relationship between the tables).  You need a
> compound index on the two foreign keys no matter what, so why throw an
> AN on top of that?
> 
> Jim.
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Tuesday, August 12, 2014 05:48 PM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD] Field
> linked to different tables
> 
> Because indexing on a Long is more efficient than indexing on a
> character string?
> 
> (It's computationally much faster and uses far less storage).
> 
> -- 
> Stuart
> 
> 
> On 12 Aug 2014 at 13:14, Jim Dettman wrote:
> 
> > <<why give a list of countries an ANPK when there already exists a
> > well-defined ISO list of countries, each having a unique char code>>
> > 
> >  Someone on my side of the fence for a change<g>
> > 
> > Jim. 
> > 
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
> > Fuller Sent: Tuesday, August 12, 2014 11:39 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Field linked
> > to different tables
> > 
> > David,
> > 
> > I've had to skin a cat like this a few times in the past, and agree
> > with Gustav's suggestion. In fact, the experience has caused me, in
> > several situations, to re-think the whole knee-jerk AutoNumberPK
> > thins that I once depended on to the exclusion of logic and common
> > sense. (For example, why give a list of countries an ANPK when there
> > already exists a well-defined ISO list of countries, each having a
> > unique char code?)
> > 
> > Arthur
> > 
> > 
> > On Mon, Aug 11, 2014 at 8:24 PM, David Emerson
> > <newsgrps at dalyn.co.nz> wrote:
> > 
> > > Thanks for the reply Stuart.  This will still have the problem in
> > > the combobox that it may not show the correct selected record if
> > > the ID's from the various tables in the first column double up.
> > >
> > > Gustav suggested making a composite key that combines the
> > > "WhoAboutType" and source table ID's so that there will not be any
> > > replications.  This will solve the problem.
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > > McLachlan Sent: Tuesday, 12 August 2014 12:06 p.m. To: Access
> > > Developers discussion and problem solving Subject: Re: [AccessD]
> > > Field linked to different tables
> > >
> > > How about another field in the Notes table "WhoAboutType"  (1 for
> > > Client,
> > 2
> > > for Staff, 3 for Company or whatever)
> > >
> > > Then
> > > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> > tblClients
> > > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName
> > > from tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as
> > > EntityName from tblCompany.
> > >
> > >
> > > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> > >
> > >
> > > --
> > > Stuart
> > >
> > > On 11 Aug 2014 at 15:23, David Emerson wrote:
> > >
> > > > Hi Listers,
> > > >
> > > >
> > > >
> > > > I am looking for some data structure advice.  I will use a
> > > > simple example but the real world application will be more
> > > > complicated.
> > > >
> > > >
> > > >
> > > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > > LinkRecordID.
> > > >
> > > >
> > > >
> > > > WhoAbout could be Client, Staff member, or Company.
> > > >
> > > > LinkRecordID is the ID from the Client, Staff member, or Company
> > > > table depending on what was selected in the WhoAbout field.
> > > >
> > > >
> > > >
> > > > The records from the Notes table will be displayed in a
> > > > continuous form showing WhoAbout and the name from the
> > > > corresponding table for the record selected in LinkRecordID.
> > > >
> > > >
> > > >
> > > > The Linkrecord field on the form is a combobox with a union of
> > > > the records from the three tables.  Data from all three tables
> > > > are needed because it is a continuous form and I don't want to
> > > > change the recordsource for each current row as this would show
> > > > incorrect data in other rows.
> > > >
> > > >
> > > >
> > > > Immediate problem: Even though I could put code in place to
> > > > ensure that the record selected is of the same type as the
> > > > WhoAbout field the correct row may not show if it has the same
> > > > ID as another record from one of the other tables.
> > > >
> > > >
> > > >
> > > > Question:  Has anyone else come across this problem and what
> > > > might be the solution?
> > > >
> > > >
> > > >
> > > > Regards
> > > >
> > > > David Emerson
> > > > Dalyn Software Ltd
> > > > Wellington, New Zealand
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > AccessD mailing list
> > > > AccessD at databaseadvisors.com
> > > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > > Website: http://www.databaseadvisors.com
> > > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > 
> > 
> > 
> > -- 
> > Arthur
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From jimdettman at verizon.net  Wed Aug 13 07:47:42 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Wed, 13 Aug 2014 08:47:42 -0400
Subject: [AccessD] Field linked to different tables
In-Reply-To: <53EAD3E9.7971.C99D4DB5@stuart.lexacorp.com.pg>
References: <004301cfb513$a56e5070$f04af150$@dalyn.co.nz>,
	<53EA8BA4.3495.C88302FA@stuart.lexacorp.com.pg>,
	<0E13EF2818A84C999F789AA78C3C9909@XPS>
	<53EAD3E9.7971.C99D4DB5@stuart.lexacorp.com.pg>
Message-ID: <12B5516F845747C58993FC1D6F231CDC@XPS>

<< An initial two bytes to storelength of the string, followed by the
characters stored as  2 byte WCHARs.>>

  Your right, JET 4.0 did jump up to a two byte off-set (the off-set is from
the start of the row to the start of the data, not the length of the column)
but each character is only stored two bytes wide if your not using Unicode
compression.  Even with that however, you'd only come out ahead if the key
was only one byte, which is hardly useful.   JET 3.x was a little different
in that only one byte was used and the data page definition was done
differently, so there was an advantage with the smaller keys.

 I'd say though that I'm really more concerned about things at a "macro"
level. For the apps I write, I'm more concerned with issues that impact
users such as concurrency, so having more indexes than I really need is a
waste.

 I should add that like everyone else, I use AN for the main index just
about everywhere, but there are places where I feel it's silly to have one
for the sake of having one (the M-M being one example).

Jim.

  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Tuesday, August 12, 2014 10:57 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Field linked to different tables

True, a Long is four bytes.

But the minimum length of a non-Null string is also four bytes.  An initial
two bytes to 
storelength of the string, followed by the characters stored as  2 byte
WCHARs.

So a four character string actually requires 10 bytes of storage.   Strings
take a lot more 
storage than longs. 

As for searching,  It only requires one operation to compare two 32 bit
values (i.e. longs).  
String comparisons take orders of magnitude more time to do.

I agree with you totally about link tables.  They are a different matter
entirely. If you consider it 
from an Entity/Relationship perspective, unlike a normal data table -  they
do not contain 
entity data, only relationship information.  By their nature, they do not
require a separate key.

-- 
Stuart


On 12 Aug 2014 at 22:11, Jim Dettman wrote:

> 
>  I think it would depend on the string.  
> 
>  Gains in the difference in register operations could be far out
>  weighed by
> the gain in index operations.   As a simple example, a long is four
> bytes, which means any string key shorter than that would pack more
> key entries per index page.   Search operations would be faster as a
> result
> 
>  And that's besides the fact that I'd have one less index on the table
>  to
> maintain.
> 
>  One place I think it's silly to have a AN as a primary key is a many
>  to
> many linking table (assuming it has no additional attributes other
> than expressing the relationship between the tables).  You need a
> compound index on the two foreign keys no matter what, so why throw an
> AN on top of that?
> 
> Jim.
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Tuesday, August 12, 2014 05:48 PM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD] Field
> linked to different tables
> 
> Because indexing on a Long is more efficient than indexing on a
> character string?
> 
> (It's computationally much faster and uses far less storage).
> 
> -- 
> Stuart
> 
> 
> On 12 Aug 2014 at 13:14, Jim Dettman wrote:
> 
> > <<why give a list of countries an ANPK when there already exists a
> > well-defined ISO list of countries, each having a unique char code>>
> > 
> >  Someone on my side of the fence for a change<g>
> > 
> > Jim. 
> > 
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
> > Fuller Sent: Tuesday, August 12, 2014 11:39 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Field linked
> > to different tables
> > 
> > David,
> > 
> > I've had to skin a cat like this a few times in the past, and agree
> > with Gustav's suggestion. In fact, the experience has caused me, in
> > several situations, to re-think the whole knee-jerk AutoNumberPK
> > thins that I once depended on to the exclusion of logic and common
> > sense. (For example, why give a list of countries an ANPK when there
> > already exists a well-defined ISO list of countries, each having a
> > unique char code?)
> > 
> > Arthur
> > 
> > 
> > On Mon, Aug 11, 2014 at 8:24 PM, David Emerson
> > <newsgrps at dalyn.co.nz> wrote:
> > 
> > > Thanks for the reply Stuart.  This will still have the problem in
> > > the combobox that it may not show the correct selected record if
> > > the ID's from the various tables in the first column double up.
> > >
> > > Gustav suggested making a composite key that combines the
> > > "WhoAboutType" and source table ID's so that there will not be any
> > > replications.  This will solve the problem.
> > >
> > > Regards
> > >
> > > David Emerson
> > > Dalyn Software Ltd
> > > Wellington, New Zealand
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > > McLachlan Sent: Tuesday, 12 August 2014 12:06 p.m. To: Access
> > > Developers discussion and problem solving Subject: Re: [AccessD]
> > > Field linked to different tables
> > >
> > > How about another field in the Notes table "WhoAboutType"  (1 for
> > > Client,
> > 2
> > > for Staff, 3 for Company or whatever)
> > >
> > > Then
> > > Select 1 as WAType, ClientPK as PK, CLientName as EntityName frm
> > tblClients
> > > UNION Select 2 as WAType, StaffPK as PK, StaffName as EntityName
> > > from tblStaff UNION Select 3 as WAType, CompanyPK as PK, CoName as
> > > EntityName from tblCompany.
> > >
> > >
> > > Then Join on (WAType  = WhoAboutType and PK = LinkRecordID)
> > >
> > >
> > > --
> > > Stuart
> > >
> > > On 11 Aug 2014 at 15:23, David Emerson wrote:
> > >
> > > > Hi Listers,
> > > >
> > > >
> > > >
> > > > I am looking for some data structure advice.  I will use a
> > > > simple example but the real world application will be more
> > > > complicated.
> > > >
> > > >
> > > >
> > > > I have a Notes table.  The Notes table fields include WhoAbout,
> > > > LinkRecordID.
> > > >
> > > >
> > > >
> > > > WhoAbout could be Client, Staff member, or Company.
> > > >
> > > > LinkRecordID is the ID from the Client, Staff member, or Company
> > > > table depending on what was selected in the WhoAbout field.
> > > >
> > > >
> > > >
> > > > The records from the Notes table will be displayed in a
> > > > continuous form showing WhoAbout and the name from the
> > > > corresponding table for the record selected in LinkRecordID.
> > > >
> > > >
> > > >
> > > > The Linkrecord field on the form is a combobox with a union of
> > > > the records from the three tables.  Data from all three tables
> > > > are needed because it is a continuous form and I don't want to
> > > > change the recordsource for each current row as this would show
> > > > incorrect data in other rows.
> > > >
> > > >
> > > >
> > > > Immediate problem: Even though I could put code in place to
> > > > ensure that the record selected is of the same type as the
> > > > WhoAbout field the correct row may not show if it has the same
> > > > ID as another record from one of the other tables.
> > > >
> > > >
> > > >
> > > > Question:  Has anyone else come across this problem and what
> > > > might be the solution?
> > > >
> > > >
> > > >
> > > > Regards
> > > >
> > > > David Emerson
> > > > Dalyn Software Ltd
> > > > Wellington, New Zealand
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > AccessD mailing list
> > > > AccessD at databaseadvisors.com
> > > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > > Website: http://www.databaseadvisors.com
> > > >
> > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > 
> > 
> > 
> > -- 
> > Arthur
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From cjlabs at att.net  Wed Aug 13 09:18:55 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 09:18:55 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
Message-ID: <942592F7E4804987A13DE0675BA1C5F5@Dell>

Cross-posted

Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win XP/Vista/7/8


I have a sub that saves a indivualized report as a pdf file, then creates an email in Outlook (late binding) and attaches the report for that individual.   It's been working fine for years.

Over the past few months, I've been hearing from users that they are getting an error from Outlook -- Method 'Subject' of object'_Mailterm' failed    I haven't been able to find anything on this error when I do a search, but anecdotally from my users, it seems related to the attachment.   Similar code without the attachment apparently works OK.

I can't reproduce the error on my Win8 computer and am at a loss.


TIA,
Carolyn Johnson

From jackandpat.d at gmail.com  Wed Aug 13 09:45:22 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Wed, 13 Aug 2014 10:45:22 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <942592F7E4804987A13DE0675BA1C5F5@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
	<942592F7E4804987A13DE0675BA1C5F5@Dell>
Message-ID: <CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>

I did a google search and found similar messages. These links may be
helpful, I hope.
I am not an Outlook programmer, but thought the links or links within may
be helpful.

http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html

Good luck.


On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net> wrote:

> Cross-posted
>
> Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
> XP/Vista/7/8
>
>
> I have a sub that saves a indivualized report as a pdf file, then creates
> an email in Outlook (late binding) and attaches the report for that
> individual.   It's been working fine for years.
>
> Over the past few months, I've been hearing from users that they are
> getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
> failed    I haven't been able to find anything on this error when I do a
> search, but anecdotally from my users, it seems related to the attachment.
>   Similar code without the attachment apparently works OK.
>
> I can't reproduce the error on my Win8 computer and am at a loss.
>
>
> TIA,
> Carolyn Johnson
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From cjlabs at att.net  Wed Aug 13 10:07:35 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 10:07:35 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
Message-ID: <B1200B596CF34031ABF6C53BB3C7426B@Dell>

Thanks.   I had seen the first post, but not the second, which seems to be saying it is a permissions issue.


Carolyn Johnson

  ----- Original Message ----- 
  From: jack drawbridge 
  To: Access Developers discussion and problem solving 
  Sent: Wednesday, August 13, 2014 9:45 AM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  I did a google search and found similar messages. These links may be
  helpful, I hope.
  I am not an Outlook programmer, but thought the links or links within may
  be helpful.

  http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
  http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html

  Good luck.


  On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net> wrote:

  > Cross-posted
  >
  > Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
  > XP/Vista/7/8
  >
  >
  > I have a sub that saves a indivualized report as a pdf file, then creates
  > an email in Outlook (late binding) and attaches the report for that
  > individual.   It's been working fine for years.
  >
  > Over the past few months, I've been hearing from users that they are
  > getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
  > failed    I haven't been able to find anything on this error when I do a
  > search, but anecdotally from my users, it seems related to the attachment.
  >   Similar code without the attachment apparently works OK.
  >
  > I can't reproduce the error on my Win8 computer and am at a loss.
  >
  >
  > TIA,
  > Carolyn Johnson
  > --
  > AccessD mailing list
  > AccessD at databaseadvisors.com
  > http://databaseadvisors.com/mailman/listinfo/accessd
  > Website: http://www.databaseadvisors.com
  >
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From bradm at blackforestltd.com  Wed Aug 13 10:08:06 2014
From: bradm at blackforestltd.com (Brad Marks)
Date: Wed, 13 Aug 2014 15:08:06 +0000
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
	<942592F7E4804987A13DE0675BA1C5F5@Dell>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
Message-ID: <09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>

Carolyn,

I have a number of nightly "Access Batch Jobs" that create many reports in PDF format and automatically e-mail these PDF files to select employees.

When I first started this project, I tried to use Outlook but ran into many time consuming issues.

I then did some research and started to experiment with a free command line e-mail utility called Blat.  Blat worked Okay, but when I ran into some problems, I spent a lot of time and could not get good answers from anyone, so I decided to try the free trial version of a command line e-mailer called Febooti.

I had immediate success with Febooti and decided to purchase the product (less than $100).  For the past two years, Febooti has worked very well for us.  It was money well spent for us.

You might not be interested in switching horses, but I thought that my experience might be useful to you.

Brad Marks    



-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
Sent: Wednesday, August 13, 2014 9:45 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

I did a google search and found similar messages. These links may be helpful, I hope.
I am not an Outlook programmer, but thought the links or links within may be helpful.

http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html

Good luck.


On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net> wrote:

> Cross-posted
>
> Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
> XP/Vista/7/8
>
>
> I have a sub that saves a indivualized report as a pdf file, then 
> creates an email in Outlook (late binding) and attaches the report for that
> individual.   It's been working fine for years.
>
> Over the past few months, I've been hearing from users that they are 
> getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
> failed    I haven't been able to find anything on this error when I do a
> search, but anecdotally from my users, it seems related to the attachment.
>   Similar code without the attachment apparently works OK.
>
> I can't reproduce the error on my Win8 computer and am at a loss.
>
>
> TIA,
> Carolyn Johnson
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jimdettman at verizon.net  Wed Aug 13 10:15:42 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Wed, 13 Aug 2014 11:15:42 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
	<942592F7E4804987A13DE0675BA1C5F5@Dell>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
Message-ID: <4FEBEBE53A6E41D9867D986179C5131A@XPS>


 There's also vbSendMail, which some on the list have used.  It does require
a DLL to be registered however....someone had code for that though.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
Sent: Wednesday, August 13, 2014 11:08 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

Carolyn,

I have a number of nightly "Access Batch Jobs" that create many reports in
PDF format and automatically e-mail these PDF files to select employees.

When I first started this project, I tried to use Outlook but ran into many
time consuming issues.

I then did some research and started to experiment with a free command line
e-mail utility called Blat.  Blat worked Okay, but when I ran into some
problems, I spent a lot of time and could not get good answers from anyone,
so I decided to try the free trial version of a command line e-mailer called
Febooti.

I had immediate success with Febooti and decided to purchase the product
(less than $100).  For the past two years, Febooti has worked very well for
us.  It was money well spent for us.

You might not be interested in switching horses, but I thought that my
experience might be useful to you.

Brad Marks    



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
Sent: Wednesday, August 13, 2014 9:45 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

I did a google search and found similar messages. These links may be
helpful, I hope.
I am not an Outlook programmer, but thought the links or links within may be
helpful.

http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html

Good luck.


On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net> wrote:

> Cross-posted
>
> Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
> XP/Vista/7/8
>
>
> I have a sub that saves a indivualized report as a pdf file, then 
> creates an email in Outlook (late binding) and attaches the report for
that
> individual.   It's been working fine for years.
>
> Over the past few months, I've been hearing from users that they are 
> getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
> failed    I haven't been able to find anything on this error when I do a
> search, but anecdotally from my users, it seems related to the attachment.
>   Similar code without the attachment apparently works OK.
>
> I can't reproduce the error on my Win8 computer and am at a loss.
>
>
> TIA,
> Carolyn Johnson
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From cjlabs at att.net  Wed Aug 13 10:37:14 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 10:37:14 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell><CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com><09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<4FEBEBE53A6E41D9867D986179C5131A@XPS>
Message-ID: <F4595999AA8844F3B1E050A6986BFC7A@Dell>

I've glanced at other options over the years but was trying to keep away from anything that has a DLL to deal with.

I am thinking it's a permissions problem, but I don't know specifically what to tell the users to look for.   The folder in which the generated pdf file is temporarily saved?   I don't know anything about that side of things.



Thanks
Carolyn

  ----- Original Message ----- 
  From: Jim Dettman 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 10:15 AM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8



   There's also vbSendMail, which some on the list have used.  It does require
  a DLL to be registered however....someone had code for that though.

  Jim. 

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
  Sent: Wednesday, August 13, 2014 11:08 AM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  Carolyn,

  I have a number of nightly "Access Batch Jobs" that create many reports in
  PDF format and automatically e-mail these PDF files to select employees.

  When I first started this project, I tried to use Outlook but ran into many
  time consuming issues.

  I then did some research and started to experiment with a free command line
  e-mail utility called Blat.  Blat worked Okay, but when I ran into some
  problems, I spent a lot of time and could not get good answers from anyone,
  so I decided to try the free trial version of a command line e-mailer called
  Febooti.

  I had immediate success with Febooti and decided to purchase the product
  (less than $100).  For the past two years, Febooti has worked very well for
  us.  It was money well spent for us.

  You might not be interested in switching horses, but I thought that my
  experience might be useful to you.

  Brad Marks    



  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
  Sent: Wednesday, August 13, 2014 9:45 AM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  I did a google search and found similar messages. These links may be
  helpful, I hope.
  I am not an Outlook programmer, but thought the links or links within may be
  helpful.

  http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
  http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html

  Good luck.


  On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net> wrote:

  > Cross-posted
  >
  > Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
  > XP/Vista/7/8
  >
  >
  > I have a sub that saves a indivualized report as a pdf file, then 
  > creates an email in Outlook (late binding) and attaches the report for
  that
  > individual.   It's been working fine for years.
  >
  > Over the past few months, I've been hearing from users that they are 
  > getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
  > failed    I haven't been able to find anything on this error when I do a
  > search, but anecdotally from my users, it seems related to the attachment.
  >   Similar code without the attachment apparently works OK.
  >
  > I can't reproduce the error on my Win8 computer and am at a loss.
  >
  >
  > TIA,
  > Carolyn Johnson
  > --
  > AccessD mailing list
  > AccessD at databaseadvisors.com
  > http://databaseadvisors.com/mailman/listinfo/accessd
  > Website: http://www.databaseadvisors.com
  >
  --
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From jackandpat.d at gmail.com  Wed Aug 13 11:30:32 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Wed, 13 Aug 2014 12:30:32 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <F4595999AA8844F3B1E050A6986BFC7A@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
	<942592F7E4804987A13DE0675BA1C5F5@Dell>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<4FEBEBE53A6E41D9867D986179C5131A@XPS>
	<F4595999AA8844F3B1E050A6986BFC7A@Dell>
Message-ID: <CAKvidAu_RZR4bQqUbng092jHWb675V4-5T77hzG++RVSNg_Ckg@mail.gmail.com>

Carolyn,
Just saw this one. It isn't a solution but adjusting the Error Handler may
give you some specifics if/when this happens.
http://www.utteraccess.com/forum/lofiversion/index.php/t2008472.html


On Wed, Aug 13, 2014 at 11:37 AM, Carolyn Johnson <cjlabs at att.net> wrote:

> I've glanced at other options over the years but was trying to keep away
> from anything that has a DLL to deal with.
>
> I am thinking it's a permissions problem, but I don't know specifically
> what to tell the users to look for.   The folder in which the generated pdf
> file is temporarily saved?   I don't know anything about that side of
> things.
>
>
>
> Thanks
> Carolyn
>
>   ----- Original Message -----
>   From: Jim Dettman
>   To: 'Access Developers discussion and problem solving'
>   Sent: Wednesday, August 13, 2014 10:15 AM
>   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
>
>
>
>    There's also vbSendMail, which some on the list have used.  It does
> require
>   a DLL to be registered however....someone had code for that though.
>
>   Jim.
>
>   -----Original Message-----
>   From: accessd-bounces at databaseadvisors.com
>   [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
>   Sent: Wednesday, August 13, 2014 11:08 AM
>   To: Access Developers discussion and problem solving
>   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
>
>   Carolyn,
>
>   I have a number of nightly "Access Batch Jobs" that create many reports
> in
>   PDF format and automatically e-mail these PDF files to select employees.
>
>   When I first started this project, I tried to use Outlook but ran into
> many
>   time consuming issues.
>
>   I then did some research and started to experiment with a free command
> line
>   e-mail utility called Blat.  Blat worked Okay, but when I ran into some
>   problems, I spent a lot of time and could not get good answers from
> anyone,
>   so I decided to try the free trial version of a command line e-mailer
> called
>   Febooti.
>
>   I had immediate success with Febooti and decided to purchase the product
>   (less than $100).  For the past two years, Febooti has worked very well
> for
>   us.  It was money well spent for us.
>
>   You might not be interested in switching horses, but I thought that my
>   experience might be useful to you.
>
>   Brad Marks
>
>
>
>   -----Original Message-----
>   From: accessd-bounces at databaseadvisors.com
>   [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack
> drawbridge
>   Sent: Wednesday, August 13, 2014 9:45 AM
>   To: Access Developers discussion and problem solving
>   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
>
>   I did a google search and found similar messages. These links may be
>   helpful, I hope.
>   I am not an Outlook programmer, but thought the links or links within
> may be
>   helpful.
>
>   http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
>   http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html
>
>   Good luck.
>
>
>   On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net>
> wrote:
>
>   > Cross-posted
>   >
>   > Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
>   > XP/Vista/7/8
>   >
>   >
>   > I have a sub that saves a indivualized report as a pdf file, then
>   > creates an email in Outlook (late binding) and attaches the report for
>   that
>   > individual.   It's been working fine for years.
>   >
>   > Over the past few months, I've been hearing from users that they are
>   > getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
>   > failed    I haven't been able to find anything on this error when I do
> a
>   > search, but anecdotally from my users, it seems related to the
> attachment.
>   >   Similar code without the attachment apparently works OK.
>   >
>   > I can't reproduce the error on my Win8 computer and am at a loss.
>   >
>   >
>   > TIA,
>   > Carolyn Johnson
>   > --
>   > AccessD mailing list
>   > AccessD at databaseadvisors.com
>   > http://databaseadvisors.com/mailman/listinfo/accessd
>   > Website: http://www.databaseadvisors.com
>   >
>   --
>   AccessD mailing list
>   AccessD at databaseadvisors.com
>   http://databaseadvisors.com/mailman/listinfo/accessd
>   Website: http://www.databaseadvisors.com
>
>   --
>   AccessD mailing list
>   AccessD at databaseadvisors.com
>   http://databaseadvisors.com/mailman/listinfo/accessd
>   Website: http://www.databaseadvisors.com
>
>   --
>   AccessD mailing list
>   AccessD at databaseadvisors.com
>   http://databaseadvisors.com/mailman/listinfo/accessd
>   Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From cjlabs at att.net  Wed Aug 13 11:36:46 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 11:36:46 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell><CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com><09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com><4FEBEBE53A6E41D9867D986179C5131A@XPS><F4595999AA8844F3B1E050A6986BFC7A@Dell>
	<CAKvidAu_RZR4bQqUbng092jHWb675V4-5T77hzG++RVSNg_Ckg@mail.gmail.com>
Message-ID: <E42BFA4A3D7B4F79A01ED71225D1DA3D@Dell>

I can add a better error handler (the one in it is pretty generic), but my problem is that I don't get the error on any of my computers.   It's people all over the country, most of whom are computer-illiterate.   But maybe someone would give me the info.


Thanks
Carolyn
  ----- Original Message ----- 
  From: jack drawbridge 
  To: Access Developers discussion and problem solving 
  Sent: Wednesday, August 13, 2014 11:30 AM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  Carolyn,
  Just saw this one. It isn't a solution but adjusting the Error Handler may
  give you some specifics if/when this happens.
  http://www.utteraccess.com/forum/lofiversion/index.php/t2008472.html


  On Wed, Aug 13, 2014 at 11:37 AM, Carolyn Johnson <cjlabs at att.net> wrote:

  > I've glanced at other options over the years but was trying to keep away
  > from anything that has a DLL to deal with.
  >
  > I am thinking it's a permissions problem, but I don't know specifically
  > what to tell the users to look for.   The folder in which the generated pdf
  > file is temporarily saved?   I don't know anything about that side of
  > things.
  >
  >
  >
  > Thanks
  > Carolyn
  >
  >   ----- Original Message -----
  >   From: Jim Dettman
  >   To: 'Access Developers discussion and problem solving'
  >   Sent: Wednesday, August 13, 2014 10:15 AM
  >   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
  >
  >
  >
  >    There's also vbSendMail, which some on the list have used.  It does
  > require
  >   a DLL to be registered however....someone had code for that though.
  >
  >   Jim.
  >
  >   -----Original Message-----
  >   From: accessd-bounces at databaseadvisors.com
  >   [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
  >   Sent: Wednesday, August 13, 2014 11:08 AM
  >   To: Access Developers discussion and problem solving
  >   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
  >
  >   Carolyn,
  >
  >   I have a number of nightly "Access Batch Jobs" that create many reports
  > in
  >   PDF format and automatically e-mail these PDF files to select employees.
  >
  >   When I first started this project, I tried to use Outlook but ran into
  > many
  >   time consuming issues.
  >
  >   I then did some research and started to experiment with a free command
  > line
  >   e-mail utility called Blat.  Blat worked Okay, but when I ran into some
  >   problems, I spent a lot of time and could not get good answers from
  > anyone,
  >   so I decided to try the free trial version of a command line e-mailer
  > called
  >   Febooti.
  >
  >   I had immediate success with Febooti and decided to purchase the product
  >   (less than $100).  For the past two years, Febooti has worked very well
  > for
  >   us.  It was money well spent for us.
  >
  >   You might not be interested in switching horses, but I thought that my
  >   experience might be useful to you.
  >
  >   Brad Marks
  >
  >
  >
  >   -----Original Message-----
  >   From: accessd-bounces at databaseadvisors.com
  >   [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack
  > drawbridge
  >   Sent: Wednesday, August 13, 2014 9:45 AM
  >   To: Access Developers discussion and problem solving
  >   Subject: Re: [AccessD] Error creating emails in Outlook in Win8
  >
  >   I did a google search and found similar messages. These links may be
  >   helpful, I hope.
  >   I am not an Outlook programmer, but thought the links or links within
  > may be
  >   helpful.
  >
  >   http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
  >   http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html
  >
  >   Good luck.
  >
  >
  >   On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net>
  > wrote:
  >
  >   > Cross-posted
  >   >
  >   > Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
  >   > XP/Vista/7/8
  >   >
  >   >
  >   > I have a sub that saves a indivualized report as a pdf file, then
  >   > creates an email in Outlook (late binding) and attaches the report for
  >   that
  >   > individual.   It's been working fine for years.
  >   >
  >   > Over the past few months, I've been hearing from users that they are
  >   > getting an error from Outlook -- Method 'Subject' of object'_Mailterm'
  >   > failed    I haven't been able to find anything on this error when I do
  > a
  >   > search, but anecdotally from my users, it seems related to the
  > attachment.
  >   >   Similar code without the attachment apparently works OK.
  >   >
  >   > I can't reproduce the error on my Win8 computer and am at a loss.
  >   >
  >   >
  >   > TIA,
  >   > Carolyn Johnson
  >   > --
  >   > AccessD mailing list
  >   > AccessD at databaseadvisors.com
  >   > http://databaseadvisors.com/mailman/listinfo/accessd
  >   > Website: http://www.databaseadvisors.com
  >   >
  >   --
  >   AccessD mailing list
  >   AccessD at databaseadvisors.com
  >   http://databaseadvisors.com/mailman/listinfo/accessd
  >   Website: http://www.databaseadvisors.com
  >
  >   --
  >   AccessD mailing list
  >   AccessD at databaseadvisors.com
  >   http://databaseadvisors.com/mailman/listinfo/accessd
  >   Website: http://www.databaseadvisors.com
  >
  >   --
  >   AccessD mailing list
  >   AccessD at databaseadvisors.com
  >   http://databaseadvisors.com/mailman/listinfo/accessd
  >   Website: http://www.databaseadvisors.com
  > --
  > AccessD mailing list
  > AccessD at databaseadvisors.com
  > http://databaseadvisors.com/mailman/listinfo/accessd
  > Website: http://www.databaseadvisors.com
  >
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From jimdettman at verizon.net  Wed Aug 13 11:54:12 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Wed, 13 Aug 2014 12:54:12 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <942592F7E4804987A13DE0675BA1C5F5@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<53EB6C69.9070400@emilia-maxim.de>
	<83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk>
	<942592F7E4804987A13DE0675BA1C5F5@Dell>
Message-ID: <93A7C229935246CDA8E9B8C5727FDE22@XPS>

Carolyn,

 Do the users receiving the errors receive them consistently or no?   Do you
do anything different with the subject line when an attachment exists?

 I think as a starting point I'd check for add-ins in Outlook and disable
them.  Also since your using Outlook, are you using any 3rd party libs to
avoid the security prompts?  If so, I'd check that your up to date with any
changes.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
Sent: Wednesday, August 13, 2014 10:19 AM
To: Microsoft Access Database Discussion List
Cc: Access Developers
Subject: [AccessD] Error creating emails in Outlook in Win8

Cross-posted

Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
XP/Vista/7/8


I have a sub that saves a indivualized report as a pdf file, then creates an
email in Outlook (late binding) and attaches the report for that individual.
It's been working fine for years.

Over the past few months, I've been hearing from users that they are getting
an error from Outlook -- Method 'Subject' of object'_Mailterm' failed    I
haven't been able to find anything on this error when I do a search, but
anecdotally from my users, it seems related to the attachment.   Similar
code without the attachment apparently works OK.

I can't reproduce the error on my Win8 computer and am at a loss.


TIA,
Carolyn Johnson
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From cjlabs at att.net  Wed Aug 13 11:59:16 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 11:59:16 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>
	<93A7C229935246CDA8E9B8C5727FDE22@XPS>
Message-ID: <7D79CC8B218440789AC8DE4DEB061A0D@Dell>

My understanding is that they are consistently getting the error -- they cannot use the procedure at all.

There is nothing different about the subject line.

I'm not getting the error on any of my computers.   I would have to check with the people who do get the error to see what their Outlook settings are.

There's no 3rd party software being used.

The only thing I've learned so far is that it may be a permissions issue on their computers, but that may be difficult for me to verify.



Thanks
Carolyn Johnson

  ----- Original Message ----- 
  From: Jim Dettman 
  To: 'Access Developers discussion and problem solving' ; 'Microsoft Access Database Discussion List' 
  Sent: Wednesday, August 13, 2014 11:54 AM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  Carolyn,

   Do the users receiving the errors receive them consistently or no?   Do you
  do anything different with the subject line when an attachment exists?

   I think as a starting point I'd check for add-ins in Outlook and disable
  them.  Also since your using Outlook, are you using any 3rd party libs to
  avoid the security prompts?  If so, I'd check that your up to date with any
  changes.

  Jim.

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 10:19 AM
  To: Microsoft Access Database Discussion List
  Cc: Access Developers
  Subject: [AccessD] Error creating emails in Outlook in Win8

  Cross-posted

  Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
  XP/Vista/7/8


  I have a sub that saves a indivualized report as a pdf file, then creates an
  email in Outlook (late binding) and attaches the report for that individual.
  It's been working fine for years.

  Over the past few months, I've been hearing from users that they are getting
  an error from Outlook -- Method 'Subject' of object'_Mailterm' failed    I
  haven't been able to find anything on this error when I do a search, but
  anecdotally from my users, it seems related to the attachment.   Similar
  code without the attachment apparently works OK.

  I can't reproduce the error on my Win8 computer and am at a loss.


  TIA,
  Carolyn Johnson
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From dw-murphy at cox.net  Wed Aug 13 14:25:20 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Wed, 13 Aug 2014 12:25:20 -0700
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <eGzz1o01C0xgD8Z01H0201>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS>
	<eGzz1o01C0xgD8Z01H0201>
Message-ID: <006901cfb72c$52474440$f6d5ccc0$@cox.net>

These types of things are really hard to trace unless you can duplicate the
error. Assuming you're not using an mde or acccde front end file I'd select
a user you know and see if you can do a remote session with them using
Remote Desktop, Techinline, Team View, or your remoting app of choice and
step through the process to see where the error is generated.

Doug

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
Sent: Wednesday, August 13, 2014 9:59 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

My understanding is that they are consistently getting the error -- they
cannot use the procedure at all.

There is nothing different about the subject line.

I'm not getting the error on any of my computers.   I would have to check
with the people who do get the error to see what their Outlook settings are.

There's no 3rd party software being used.

The only thing I've learned so far is that it may be a permissions issue on
their computers, but that may be difficult for me to verify.



Thanks
Carolyn Johnson

  ----- Original Message ----- 
  From: Jim Dettman 
  To: 'Access Developers discussion and problem solving' ; 'Microsoft Access
Database Discussion List' 
  Sent: Wednesday, August 13, 2014 11:54 AM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  Carolyn,

   Do the users receiving the errors receive them consistently or no?   Do
you
  do anything different with the subject line when an attachment exists?

   I think as a starting point I'd check for add-ins in Outlook and disable
  them.  Also since your using Outlook, are you using any 3rd party libs to
  avoid the security prompts?  If so, I'd check that your up to date with
any
  changes.

  Jim.

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 10:19 AM
  To: Microsoft Access Database Discussion List
  Cc: Access Developers
  Subject: [AccessD] Error creating emails in Outlook in Win8

  Cross-posted

  Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
  XP/Vista/7/8


  I have a sub that saves a indivualized report as a pdf file, then creates
an
  email in Outlook (late binding) and attaches the report for that
individual.
  It's been working fine for years.

  Over the past few months, I've been hearing from users that they are
getting
  an error from Outlook -- Method 'Subject' of object'_Mailterm' failed    I
  haven't been able to find anything on this error when I do a search, but
  anecdotally from my users, it seems related to the attachment.   Similar
  code without the attachment apparently works OK.

  I can't reproduce the error on my Win8 computer and am at a loss.


  TIA,
  Carolyn Johnson
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Wed Aug 13 14:45:27 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 13 Aug 2014 15:45:27 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <7D79CC8B218440789AC8DE4DEB061A0D@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS>
	<7D79CC8B218440789AC8DE4DEB061A0D@Dell>
Message-ID: <002101cfb72f$226abc40$674034c0$@gmail.com>

Carolyn are you calling the save method before .SEND ?



From cjlabs at att.net  Wed Aug 13 14:45:44 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 14:45:44 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><eGzz1o01C0xgD8Z01H0201>
	<006901cfb72c$52474440$f6d5ccc0$@cox.net>
Message-ID: <E1D2B2AD4AB1449DB0C7DB1DE985D49A@Dell>

That is a good suggestion.  Just have to figure out who that person is   :>


Thanks
Carolyn

  ----- Original Message ----- 
  From: Doug Murphy 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:25 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  These types of things are really hard to trace unless you can duplicate the
  error. Assuming you're not using an mde or acccde front end file I'd select
  a user you know and see if you can do a remote session with them using
  Remote Desktop, Techinline, Team View, or your remoting app of choice and
  step through the process to see where the error is generated.

  Doug

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 9:59 AM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  My understanding is that they are consistently getting the error -- they
  cannot use the procedure at all.

  There is nothing different about the subject line.

  I'm not getting the error on any of my computers.   I would have to check
  with the people who do get the error to see what their Outlook settings are.

  There's no 3rd party software being used.

  The only thing I've learned so far is that it may be a permissions issue on
  their computers, but that may be difficult for me to verify.



  Thanks
  Carolyn Johnson

    ----- Original Message ----- 
    From: Jim Dettman 
    To: 'Access Developers discussion and problem solving' ; 'Microsoft Access
  Database Discussion List' 
    Sent: Wednesday, August 13, 2014 11:54 AM
    Subject: Re: [AccessD] Error creating emails in Outlook in Win8


    Carolyn,

     Do the users receiving the errors receive them consistently or no?   Do
  you
    do anything different with the subject line when an attachment exists?

     I think as a starting point I'd check for add-ins in Outlook and disable
    them.  Also since your using Outlook, are you using any 3rd party libs to
    avoid the security prompts?  If so, I'd check that your up to date with
  any
    changes.

    Jim.

    -----Original Message-----
    From: accessd-bounces at databaseadvisors.com
    [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
    Sent: Wednesday, August 13, 2014 10:19 AM
    To: Microsoft Access Database Discussion List
    Cc: Access Developers
    Subject: [AccessD] Error creating emails in Outlook in Win8

    Cross-posted

    Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
    XP/Vista/7/8


    I have a sub that saves a indivualized report as a pdf file, then creates
  an
    email in Outlook (late binding) and attaches the report for that
  individual.
    It's been working fine for years.

    Over the past few months, I've been hearing from users that they are
  getting
    an error from Outlook -- Method 'Subject' of object'_Mailterm' failed    I
    haven't been able to find anything on this error when I do a search, but
    anecdotally from my users, it seems related to the attachment.   Similar
    code without the attachment apparently works OK.

    I can't reproduce the error on my Win8 computer and am at a loss.


    TIA,
    Carolyn Johnson
    -- 
    AccessD mailing list
    AccessD at databaseadvisors.com
    http://databaseadvisors.com/mailman/listinfo/accessd
    Website: http://www.databaseadvisors.com

    -- 
    AccessD mailing list
    AccessD at databaseadvisors.com
    http://databaseadvisors.com/mailman/listinfo/accessd
    Website: http://www.databaseadvisors.com
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From cjlabs at att.net  Wed Aug 13 14:52:37 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 14:52:37 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><7D79CC8B218440789AC8DE4DEB061A0D@Dell>
	<002101cfb72f$226abc40$674034c0$@gmail.com>
Message-ID: <0E179EC8C9A4455BA0D957BBAD2A857A@Dell>

No.   I don't use the save method . . . 

I create the email, create the pdf file, attach the pdf file, kill the pdf file, then send the email.   The move on to the next person in the recordset and do it again.


Carolyn
  ----- Original Message ----- 
  From: Bill Benson 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:45 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  Carolyn are you calling the save method before .SEND ?


  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From bensonforums at gmail.com  Wed Aug 13 14:54:29 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 13 Aug 2014 15:54:29 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <0E179EC8C9A4455BA0D957BBAD2A857A@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><7D79CC8B218440789AC8DE4DEB061A0D@Dell>	<002101cfb72f$226abc40$674034c0$@gmail.com>
	<0E179EC8C9A4455BA0D957BBAD2A857A@Dell>
Message-ID: <002201cfb730$6579d470$306d7d50$@gmail.com>

I believe it is important to save the email after attaching the attachment
and assigning any other properties, and then using .SEND only after using
.SAVE

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
Sent: Wednesday, August 13, 2014 3:53 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

No.   I don't use the save method . . . 

I create the email, create the pdf file, attach the pdf file, kill the pdf
file, then send the email.   The move on to the next person in the recordset
and do it again.


Carolyn
  ----- Original Message ----- 
  From: Bill Benson 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:45 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  Carolyn are you calling the save method before .SEND ?


  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From cjlabs at att.net  Wed Aug 13 14:59:55 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Wed, 13 Aug 2014 14:59:55 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><7D79CC8B218440789AC8DE4DEB061A0D@Dell>	<002101cfb72f$226abc40$674034c0$@gmail.com><0E179EC8C9A4455BA0D957BBAD2A857A@Dell>
	<002201cfb730$6579d470$306d7d50$@gmail.com>
Message-ID: <3F437EB2058E469B9E55D960F5D60F24@Dell>

It's never mattered in the past, but certainly worth a try.   Something has changed.

Thanks
Carolyn

  ----- Original Message ----- 
  From: Bill Benson 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:54 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  I believe it is important to save the email after attaching the attachment
  and assigning any other properties, and then using .SEND only after using
  .SAVE

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 3:53 PM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  No.   I don't use the save method . . . 

  I create the email, create the pdf file, attach the pdf file, kill the pdf
  file, then send the email.   The move on to the next person in the recordset
  and do it again.


  Carolyn
    ----- Original Message ----- 
    From: Bill Benson 
    To: 'Access Developers discussion and problem solving' 
    Sent: Wednesday, August 13, 2014 2:45 PM
    Subject: Re: [AccessD] Error creating emails in Outlook in Win8


    Carolyn are you calling the save method before .SEND ?


    -- 
    AccessD mailing list
    AccessD at databaseadvisors.com
    http://databaseadvisors.com/mailman/listinfo/accessd
    Website: http://www.databaseadvisors.com
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

From bensonforums at gmail.com  Wed Aug 13 15:03:29 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Wed, 13 Aug 2014 16:03:29 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <3F437EB2058E469B9E55D960F5D60F24@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><7D79CC8B218440789AC8DE4DEB061A0D@Dell>	<002101cfb72f$226abc40$674034c0$@gmail.com><0E179EC8C9A4455BA0D957BBAD2A857A@Dell>	<002201cfb730$6579d470$306d7d50$@gmail.com>
	<3F437EB2058E469B9E55D960F5D60F24@Dell>
Message-ID: <002d01cfb731$a7bf3400$f73d9c00$@gmail.com>

OK, I hope it helps.

This is the link where I say MSFT advising .SAVE first before .SEND

http://support.microsoft.com/kb/161088


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
Sent: Wednesday, August 13, 2014 4:00 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

It's never mattered in the past, but certainly worth a try.   Something has
changed.

Thanks
Carolyn

  ----- Original Message ----- 
  From: Bill Benson 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:54 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  I believe it is important to save the email after attaching the attachment
  and assigning any other properties, and then using .SEND only after using
  .SAVE

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 3:53 PM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  No.   I don't use the save method . . . 

  I create the email, create the pdf file, attach the pdf file, kill the pdf
  file, then send the email.   The move on to the next person in the
recordset
  and do it again.


  Carolyn
    ----- Original Message ----- 
    From: Bill Benson 
    To: 'Access Developers discussion and problem solving' 
    Sent: Wednesday, August 13, 2014 2:45 PM
    Subject: Re: [AccessD] Error creating emails in Outlook in Win8


    Carolyn are you calling the save method before .SEND ?


    -- 
    AccessD mailing list
    AccessD at databaseadvisors.com
    http://databaseadvisors.com/mailman/listinfo/accessd
    Website: http://www.databaseadvisors.com
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From dw-murphy at cox.net  Wed Aug 13 16:14:48 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Wed, 13 Aug 2014 14:14:48 -0700
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <eL0e1o0040xgD8Z01L0gUc>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com><53EB6C69.9070400@emilia-maxim.de><83D9B8A99D17B2459615C8C1311C3DE10B1E24D4B0@svp-mailbox01.ad.portsmouth.gov.uk><942592F7E4804987A13DE0675BA1C5F5@Dell>	<93A7C229935246CDA8E9B8C5727FDE22@XPS><7D79CC8B218440789AC8DE4DEB061A0D@Dell>	<002101cfb72f$226abc40$674034c0$@gmail.com><0E179EC8C9A4455BA0D957BBAD2A857A@Dell>	<002201cfb730$6579d470$306d7d50$@gmail.com>
	<eL0e1o0040xgD8Z01L0gUc>
Message-ID: <007601cfb73b$9d02e5c0$d708b140$@cox.net>

My guess would be that the Access application does not have permission to
write files to the directory it is working in on the erroring machines. As I
said in my previous message, nothing beats debugging on the machine giving
the error and seeing what is happening.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
Sent: Wednesday, August 13, 2014 1:00 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8

It's never mattered in the past, but certainly worth a try.   Something has
changed.

Thanks
Carolyn

  ----- Original Message ----- 
  From: Bill Benson 
  To: 'Access Developers discussion and problem solving' 
  Sent: Wednesday, August 13, 2014 2:54 PM
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8


  I believe it is important to save the email after attaching the attachment
  and assigning any other properties, and then using .SEND only after using
  .SAVE

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Carolyn Johnson
  Sent: Wednesday, August 13, 2014 3:53 PM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Error creating emails in Outlook in Win8

  No.   I don't use the save method . . . 

  I create the email, create the pdf file, attach the pdf file, kill the pdf
  file, then send the email.   The move on to the next person in the
recordset
  and do it again.


  Carolyn
    ----- Original Message ----- 
    From: Bill Benson 
    To: 'Access Developers discussion and problem solving' 
    Sent: Wednesday, August 13, 2014 2:45 PM
    Subject: Re: [AccessD] Error creating emails in Outlook in Win8


    Carolyn are you calling the save method before .SEND ?


    -- 
    AccessD mailing list
    AccessD at databaseadvisors.com
    http://databaseadvisors.com/mailman/listinfo/accessd
    Website: http://www.databaseadvisors.com
  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com

  -- 
  AccessD mailing list
  AccessD at databaseadvisors.com
  http://databaseadvisors.com/mailman/listinfo/accessd
  Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Wed Aug 13 19:25:40 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 14 Aug 2014 10:25:40 +1000
Subject: [AccessD] Error creating emails in Outlook in Win8
In-Reply-To: <09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>,
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>,
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
Message-ID: <53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>

You should have asked me about your Blat problems :)

I use it in different ways in  a lot of applications and have worked out most of gotchas.
(Both with the DLL and the EXE)

-- 
Stuart

On 13 Aug 2014 at 15:08, Brad Marks wrote:

> Carolyn,
> 
> I have a number of nightly "Access Batch Jobs" that create many
> reports in PDF format and automatically e-mail these PDF files to
> select employees.
> 
> When I first started this project, I tried to use Outlook but ran into
> many time consuming issues.
> 
> I then did some research and started to experiment with a free command
> line e-mail utility called Blat.  Blat worked Okay, but when I ran
> into some problems, I spent a lot of time and could not get good
> answers from anyone, so I decided to try the free trial version of a
> command line e-mailer called Febooti.
> 
> I had immediate success with Febooti and decided to purchase the
> product (less than $100).  For the past two years, Febooti has worked
> very well for us.  It was money well spent for us.
> 
> You might not be interested in switching horses, but I thought that my
> experience might be useful to you.
> 
> Brad Marks    
> 
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack
> drawbridge Sent: Wednesday, August 13, 2014 9:45 AM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD] Error
> creating emails in Outlook in Win8
> 
> I did a google search and found similar messages. These links may be
> helpful, I hope. I am not an Outlook programmer, but thought the links
> or links within may be helpful.
> 
> http://www.outlookcode.com/threads.aspx?forumid=2&messageid=33854
> http://www.pcreview.co.uk/forums/reading-another-inbox-t1840585.html
> 
> Good luck.
> 
> 
> On Wed, Aug 13, 2014 at 10:18 AM, Carolyn Johnson <cjlabs at att.net>
> wrote:
> 
> > Cross-posted
> >
> > Access 2000 database, running in 2000/XP, 2007, 2010, 2013 on Win
> > XP/Vista/7/8
> >
> >
> > I have a sub that saves a indivualized report as a pdf file, then
> > creates an email in Outlook (late binding) and attaches the report
> > for that individual.   It's been working fine for years.
> >
> > Over the past few months, I've been hearing from users that they are
> > getting an error from Outlook -- Method 'Subject' of
> > object'_Mailterm' failed    I haven't been able to find anything on
> > this error when I do a search, but anecdotally from my users, it
> > seems related to the attachment.
> >   Similar code without the attachment apparently works OK.
> >
> > I can't reproduce the error on my Win8 computer and am at a loss.
> >
> >
> > TIA,
> > Carolyn Johnson
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From fuller.artful at gmail.com  Tue Aug 19 11:07:51 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 19 Aug 2014 12:07:51 -0400
Subject: [AccessD] Most common problems/situations
Message-ID: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

-- 
Arthur

From jackandpat.d at gmail.com  Tue Aug 19 11:37:19 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Tue, 19 Aug 2014 12:37:19 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
Message-ID: <CAKvidAv6EceOBq4vun+TN+wf3--hVcQpW_2m6v48gnPfOpLV0w@mail.gmail.com>

Hi Arthur,

I see you are looking specifically at  Access and not database per se. I'm
on different forums and most issues I see are related to database
design/Normalization. For me, the constantly changing user interface and
the increasing preoccupation with Web databases and the "potential demise
of the traditional desktop are concerns.

A little off your requested topic......

jack


On Tue, Aug 19, 2014 at 12:07 PM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I'm trying to gather a list of the most common problems and situations
> faced by an Access developer (strictly referring to design/coding/form
> types/control types/classes, etc., and leaving aside problems such as
> time-and-billing, getting paid in a timely fashion, how to factor into your
> billing rate the depreciation on your hardware and software investments,
> etc.).
>
> The initial ones that come to mind are:
> - Input masks
> - Master/Detail forms (could be nested, as in
> Customers/Orders/OrderDetails)
> - Combo boxes (also involves Cascading Combos and NotInList behaviour)
> - List boxes (also involves NotInList behaviour)
> - Linked forms (a pair of forms; navigation on either causes navigation on
> the other)
> - Office Integration (links to Excel, Word, Outlook,etc.)
> - Custom Nav buttons (assuming you don't like those built-in)
> - On-the-fly creation of new forms/dialogs/reports
> - Search and Filter facilities
> - Reports scoped to either the current row, or criteria
> - API calls
> - Export current record/report to PDF and email same
> - (Advanced) Creation of custom classes, most commonly custom controls
>
> These are the common problems I have commonly faced and addressed. Do you
> have others to add to this list? Eagerly seeking addition to this list.
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From jamesbutton at blueyonder.co.uk  Tue Aug 19 11:52:13 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Tue, 19 Aug 2014 17:52:13 +0100
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>

Data sourcing and validation of pre-entered data
Client-owner level authority to access the data, talk to the providers, reject
bad data 
Legal authority to do the above, and to take data (or even the specifications)
off the clients registered site(s)
Backup and recovery
Audit trail
Creation of Test environment, UAT environment live environment 
Maintenance of environments - stability and consistency across the environments
Links to external environments - such as client PC's laptops   
New OS's, fixes, new DLL's new Access versions and even touchscreen, mouse, and
window resolution
Fonts  Client-end printers   
Ah! Yea - a couple of real goodies
Client not having appropriate, or even any contracts with other parties
associated with the data, or planned facilities

Cloud usage - country of data storage, ownership of the storage facilities,
backup, ISP regulations,
And appropriate guarantees of the clients (and developers) access to, and usage
of those facilities, and all the above.

I came across a project where the client had not got a contract with developers
of the feed systems or the accounts package they had bought in.
And - no agreement was included in the contract for that accounts package for
the client to have any  'ownership' of  their copy or have it modified to
conform to the requirements of the countries it was to be operated in, or under
the applicable laws.
Also no maintenance agreement for use on other than the system as-is that it was
to be initially installed on.

No - you cannot use the application on the system if you upgrade the hardware,
now drives,  memory, comms, or even apply fixes to the OS.
No - we will not 'maintain' the system to run on upgraded OS's 
No - you may not 'maintain' the system to run on upgraded OS's  
Alright - perhaps we will do changes you need for legal compliance - we'll do
that as an on-cost price to be negotiated once we have been paid to do the
changes analysis.

 JimB


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 19, 2014 5:08 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Most common problems/situations

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

-- 
Arthur
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From gustav at cactus.dk  Tue Aug 19 15:13:48 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Tue, 19 Aug 2014 20:13:48 +0000
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
Message-ID: <1408479227654.52603@cactus.dk>

Hi Arthur

Keeping individual user settings for datasheet forms (coloumn order and widths, frozen coloums, sorting, filtering). I built a system for that for a client - a major task I can tell - but why isn't that a built in (selectable) feature?

A much faster Format Conditions system. FC is very useful but very slow if you have hundreds of coloumns.

Creation of ribbons. It just can't be true that you need a third party tool to get productive on this.

A new language. "C# for Applications". Whatever other than the outdated VBA.

/gustav
________________________________________
Fra: accessd-bounces at databaseadvisors.com <accessd-bounces at databaseadvisors.com> p? vegne af Arthur Fuller <fuller.artful at gmail.com>
Sendt: 19. august 2014 18:07
Til: Access Developers discussion and problem solving
Emne: [AccessD] Most common problems/situations

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

--
Arthur

From fuller.artful at gmail.com  Tue Aug 19 16:10:10 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 19 Aug 2014 17:10:10 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
Message-ID: <CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>

Thanks so far for your input.

You raise an interesting issue, Jack; actually, a large issue, but as yet
I'm not quite sure how to fit it into the topic that I'm currently writing
about. So let me sketch a scenario.

I inherit an Access project containing lots of forms which in turn contain
a few combos and listboxes and perhaps even radio buttons. Some, perhaps
most of their data sources are SQL statements rather than named queries;
that's my first point of attack.

The first point leads to the second, which I call Atomic v. Molecular
Queries. Use your chemistry experience to figure out what this means. If
you can't get there, then this is what I mean:

1. Nothing should be table-driven; absolutely nothing.
2. All combos/lists and by extension forms, should have data sources not
directly bound to tables, but rather named queries, which can be reconsumed
in many contexts throughout the given app.
3. The reason for 2 is that the logic contained therein is portable to any
new back-end that might be required. (Maybe this doesn't affect your
particular situations and apps, but I have suffered this walk through the
park enough times to know that I ought to design for change, and keep all
options open -- and that extends beyond db-implemenation,
fe-implementation, and even Virgin 2.0.
4. To sum up my design strategy, it consists of two parts: a) Design for
Success; and b) Design for Failure. What this translates into is this:
Imagine that the app you deliver causes massive success for the client;
this will necessarily involve failures to design for scale (they wanted it
cheap and fast, and you delivered what they wanted, but now the anticipated
customer-base has grown from 1000 to 1000k and that success has created
significant new problems).

My mantra is "Design for Success". (Else why hire me?) This translates into
anticipation of the hi,deous prospect that the client might be right, and
the business will succeed, in which ugly event, you might have a contract
extending for years, and thus be able to feed your kids and pay your
mortgage for years -- even though you thought you'veten solved the basic
problem, and thought yourself free to move on.

Bad news (or good, depending on your perspective). Let's call this Fuller's
Eighth Law: bad deliveries result in aborted projects; successful
deliveries result in Requests for Improvements, or to put in crassly,
future income for you. Fuller's Ninth Law: Quality Info demands further
Quality Info (this goes under several names, the most current being Big
Data, but the principle is the same: crunch and spin -- at the end of the
day, that's what it's all about).

As for me, I design for success. I feel that if I cannot contribute to
massive success in the given client's adventure, then I have failed. The
client's focus is on increased market-penetration and hence revenue, and
some percentage of the cake.

I am no expert in any of these domains, but am acquainted in all of them. I
want to play in this arena. Ideally, I'd like to find somebody who can
appreciate what I can bring to the table. To put it another way, Retirement
is Boring.

I'm working on an eBook now, and think I am going to be at least a couple
of weeks late, and maybe a month, but I want to get it right, and if it
takes an extra month, then so be it. It's all about the reader, not the
royalties. That's my mantra.

The project has a specific goal, and is envisioned as the first of six
eBooks. That's why I am asking about the most common problems and solutions
that Access developers face. I think that I've covered my personal list,
but I need more -- I have worked in several small niches, and you have
worked in others. We share common problems, but we have also delivered
slightly odd variants of same, not to mention unique solutions to bizarre
problems.

I'm interested in all of these. This is going toward an eBook, and if
anything you contribute ends up included in said work, you shall be
credited for your contributions.

I don't think a lot of money will result from this task, but I think that
someone needs to do it, and have nominated myself as the tasktician (I
don[t think that's a word,but it's the best I could do at the moment: it
means that I shall vet the contributions, by fiat, and decide what is worth
inclusion. That might sound dictatorial, but hey, it's my project, so I get
the Veto; at the same time, any contributions you submit shall, if used, be
credited in the final output. (After all these years on these various
threads, I think you can trust me to credit any contributors.)

That said, I am most interested in your generalized descriptions of common
problems facing Access developers. I have listed those that came to me
while writing this email. I sincerely invite others, and if necessary to
illustrate the problem, a little descriptive info.

Thanks in advance. I cannot promise that your contribution will be used in
the forthcoming eBook, but if it is, then I guarantee a citation.

?

From jimdettman at verizon.net  Tue Aug 19 20:03:40 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Tue, 19 Aug 2014 21:03:40 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
Message-ID: <E4DD19F21FFE45F5BB1636EC79F381CC@XPS>

Not sure what the goal is here, but I see these:

1. Inability to do a 3tier design.
2. VBA references/"runtime environment" as it's not a true .EXE.
3. Multiple versions of Office on the same PC.
4. Lack of 3rd party controls because Access does not fully implement the
IDispatch interface.
5. Lack of control over the main Access window.

as more of a pain because there's no real good solution for any of them
expect #3 (sage) and still be an Access Developer. 

 I suppose one thing beyond that which makes life really painful is the
automatic save of a main record when you move into a sub form control.

 I'd have to say out of all the things taking Access "as is" and using it
the way that it's was intended to be used, that one causes the most
problems.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 19, 2014 12:08 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Most common problems/situations

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

-- 
Arthur
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From marksimms at verizon.net  Tue Aug 19 20:07:15 2014
From: marksimms at verizon.net (Mark Simms)
Date: Tue, 19 Aug 2014 21:07:15 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
Message-ID: <002401cfbc13$15742f10$405c8d30$@net>

Having to build in user-level access/security. They could have easily built 
this into Access forms and reports.
Instead, we have to code this in VBA classes.
Let's send this to Steve, The multibillionaire Ballmer. "Thanks Steve for 
forgetting us....and here's hoping your investments work-out".

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:accessd-
> bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 19, 2014 5:10 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Most common problems/situations
>
> Thanks so far for your input.
>
> You raise an interesting issue, Jack; actually, a large issue, but as
> yet
> I'm not quite sure how to fit it into the topic that I'm currently
> writing
> about. So let me sketch a scenario.
>
> I inherit an Access project containing lots of forms which in turn
> contain
> a few combos and listboxes and perhaps even radio buttons. Some,
> perhaps
> most of their data sources are SQL statements rather than named
> queries;
> that's my first point of attack.
>
> The first point leads to the second, which I call Atomic v. Molecular
> Queries. Use your chemistry experience to figure out what this means.
> If
> you can't get there, then this is what I mean:
>
> 1. Nothing should be table-driven; absolutely nothing.
> 2. All combos/lists and by extension forms, should have data sources
> not
> directly bound to tables, but rather named queries, which can be
> reconsumed
> in many contexts throughout the given app.
> 3. The reason for 2 is that the logic contained therein is portable to
> any
> new back-end that might be required. (Maybe this doesn't affect your
> particular situations and apps, but I have suffered this walk through
> the
> park enough times to know that I ought to design for change, and keep
> all
> options open -- and that extends beyond db-implemenation,
> fe-implementation, and even Virgin 2.0.
> 4. To sum up my design strategy, it consists of two parts: a) Design
> for
> Success; and b) Design for Failure. What this translates into is this:
> Imagine that the app you deliver causes massive success for the client;
> this will necessarily involve failures to design for scale (they wanted
> it
> cheap and fast, and you delivered what they wanted, but now the
> anticipated
> customer-base has grown from 1000 to 1000k and that success has created
> significant new problems).
>
> My mantra is "Design for Success". (Else why hire me?) This translates
> into
> anticipation of the hi,deous prospect that the client might be right,
> and
> the business will succeed, in which ugly event, you might have a
> contract
> extending for years, and thus be able to feed your kids and pay your
> mortgage for years -- even though you thought you'veten solved the
> basic
> problem, and thought yourself free to move on.
>
> Bad news (or good, depending on your perspective). Let's call this
> Fuller's
> Eighth Law: bad deliveries result in aborted projects; successful
> deliveries result in Requests for Improvements, or to put in crassly,
> future income for you. Fuller's Ninth Law: Quality Info demands further
> Quality Info (this goes under several names, the most current being Big
> Data, but the principle is the same: crunch and spin -- at the end of
> the
> day, that's what it's all about).
>
> As for me, I design for success. I feel that if I cannot contribute to
> massive success in the given client's adventure, then I have failed.
> The
> client's focus is on increased market-penetration and hence revenue,
> and
> some percentage of the cake.
>
> I am no expert in any of these domains, but am acquainted in all of
> them. I
> want to play in this arena. Ideally, I'd like to find somebody who can
> appreciate what I can bring to the table. To put it another way,
> Retirement
> is Boring.
>
> I'm working on an eBook now, and think I am going to be at least a
> couple
> of weeks late, and maybe a month, but I want to get it right, and if it
> takes an extra month, then so be it. It's all about the reader, not the
> royalties. That's my mantra.
>
> The project has a specific goal, and is envisioned as the first of six
> eBooks. That's why I am asking about the most common problems and
> solutions
> that Access developers face. I think that I've covered my personal
> list,
> but I need more -- I have worked in several small niches, and you have
> worked in others. We share common problems, but we have also delivered
> slightly odd variants of same, not to mention unique solutions to
> bizarre
> problems.
>
> I'm interested in all of these. This is going toward an eBook, and if
> anything you contribute ends up included in said work, you shall be
> credited for your contributions.
>
> I don't think a lot of money will result from this task, but I think
> that
> someone needs to do it, and have nominated myself as the tasktician (I
> don[t think that's a word,but it's the best I could do at the moment:
> it
> means that I shall vet the contributions, by fiat, and decide what is
> worth
> inclusion. That might sound dictatorial, but hey, it's my project, so I
> get
> the Veto; at the same time, any contributions you submit shall, if
> used, be
> credited in the final output. (After all these years on these various
> threads, I think you can trust me to credit any contributors.)
>
> That said, I am most interested in your generalized descriptions of
> common
> problems facing Access developers. I have listed those that came to me
> while writing this email. I sincerely invite others, and if necessary
> to
> illustrate the problem, a little descriptive info.
>
> Thanks in advance. I cannot promise that your contribution will be used
> in
> the forthcoming eBook, but if it is, then I guarantee a citation.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com



From bensonforums at gmail.com  Tue Aug 19 21:02:36 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Tue, 19 Aug 2014 22:02:36 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <002401cfbc13$15742f10$405c8d30$@net>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
	<002401cfbc13$15742f10$405c8d30$@net>
Message-ID: <006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>

You hurt his feelings Mark, now he's gone and stepped down from the MSFT
B.O.D.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms
Sent: Tuesday, August 19, 2014 9:07 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Most common problems/situations

Having to build in user-level access/security. They could have easily built
this into Access forms and reports.
Instead, we have to code this in VBA classes.
Let's send this to Steve, The multibillionaire Ballmer. "Thanks Steve for
forgetting us....and here's hoping your investments work-out".

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:accessd- 
> bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 19, 2014 5:10 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Most common problems/situations
>
> Thanks so far for your input.
>
> You raise an interesting issue, Jack; actually, a large issue, but as 
> yet I'm not quite sure how to fit it into the topic that I'm currently 
> writing about. So let me sketch a scenario.
>
> I inherit an Access project containing lots of forms which in turn 
> contain a few combos and listboxes and perhaps even radio buttons. 
> Some, perhaps most of their data sources are SQL statements rather 
> than named queries; that's my first point of attack.
>
> The first point leads to the second, which I call Atomic v. Molecular 
> Queries. Use your chemistry experience to figure out what this means.
> If
> you can't get there, then this is what I mean:
>
> 1. Nothing should be table-driven; absolutely nothing.
> 2. All combos/lists and by extension forms, should have data sources 
> not directly bound to tables, but rather named queries, which can be 
> reconsumed in many contexts throughout the given app.
> 3. The reason for 2 is that the logic contained therein is portable to 
> any new back-end that might be required. (Maybe this doesn't affect 
> your particular situations and apps, but I have suffered this walk 
> through the park enough times to know that I ought to design for 
> change, and keep all options open -- and that extends beyond 
> db-implemenation, fe-implementation, and even Virgin 2.0.
> 4. To sum up my design strategy, it consists of two parts: a) Design 
> for Success; and b) Design for Failure. What this translates into is 
> this:
> Imagine that the app you deliver causes massive success for the 
> client; this will necessarily involve failures to design for scale 
> (they wanted it cheap and fast, and you delivered what they wanted, 
> but now the anticipated customer-base has grown from 1000 to 1000k and 
> that success has created significant new problems).
>
> My mantra is "Design for Success". (Else why hire me?) This translates 
> into anticipation of the hi,deous prospect that the client might be 
> right, and the business will succeed, in which ugly event, you might 
> have a contract extending for years, and thus be able to feed your 
> kids and pay your mortgage for years -- even though you thought 
> you'veten solved the basic problem, and thought yourself free to move 
> on.
>
> Bad news (or good, depending on your perspective). Let's call this 
> Fuller's Eighth Law: bad deliveries result in aborted projects; 
> successful deliveries result in Requests for Improvements, or to put 
> in crassly, future income for you. Fuller's Ninth Law: Quality Info 
> demands further Quality Info (this goes under several names, the most 
> current being Big Data, but the principle is the same: crunch and spin 
> -- at the end of the day, that's what it's all about).
>
> As for me, I design for success. I feel that if I cannot contribute to 
> massive success in the given client's adventure, then I have failed.
> The
> client's focus is on increased market-penetration and hence revenue, 
> and some percentage of the cake.
>
> I am no expert in any of these domains, but am acquainted in all of 
> them. I want to play in this arena. Ideally, I'd like to find somebody 
> who can appreciate what I can bring to the table. To put it another 
> way, Retirement is Boring.
>
> I'm working on an eBook now, and think I am going to be at least a 
> couple of weeks late, and maybe a month, but I want to get it right, 
> and if it takes an extra month, then so be it. It's all about the 
> reader, not the royalties. That's my mantra.
>
> The project has a specific goal, and is envisioned as the first of six 
> eBooks. That's why I am asking about the most common problems and 
> solutions that Access developers face. I think that I've covered my 
> personal list, but I need more -- I have worked in several small 
> niches, and you have worked in others. We share common problems, but 
> we have also delivered slightly odd variants of same, not to mention 
> unique solutions to bizarre problems.
>
> I'm interested in all of these. This is going toward an eBook, and if 
> anything you contribute ends up included in said work, you shall be 
> credited for your contributions.
>
> I don't think a lot of money will result from this task, but I think 
> that someone needs to do it, and have nominated myself as the 
> tasktician (I don[t think that's a word,but it's the best I could do 
> at the moment:
> it
> means that I shall vet the contributions, by fiat, and decide what is 
> worth inclusion. That might sound dictatorial, but hey, it's my 
> project, so I get the Veto; at the same time, any contributions you 
> submit shall, if used, be credited in the final output. (After all 
> these years on these various threads, I think you can trust me to 
> credit any contributors.)
>
> That said, I am most interested in your generalized descriptions of 
> common problems facing Access developers. I have listed those that 
> came to me while writing this email. I sincerely invite others, and if 
> necessary to illustrate the problem, a little descriptive info.
>
> Thanks in advance. I cannot promise that your contribution will be 
> used in the forthcoming eBook, but if it is, then I guarantee a 
> citation.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From steve at datamanagementsolutions.biz  Tue Aug 19 23:24:28 2014
From: steve at datamanagementsolutions.biz (Steve Schapel)
Date: Wed, 20 Aug 2014 16:24:28 +1200
Subject: [AccessD] Most common problems/situations
In-Reply-To: <E4DD19F21FFE45F5BB1636EC79F381CC@XPS>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<E4DD19F21FFE45F5BB1636EC79F381CC@XPS>
Message-ID: <5355E6C4CCFE4345835997902CBF58C3@SteveT540p>

That's interesting, Jim.  I have never thought of the "automatic save of a 
main record when you move into a sub form control" as a problem.  Could you 
say a little more about how this causes pain?  Thanks.

Regards
Steve


-----Original Message----- 
From: Jim Dettman
Sent: Wednesday, August 20, 2014 1:03 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Most common problems/situations

Not sure what the goal is here, but I see these:

1. Inability to do a 3tier design.
2. VBA references/"runtime environment" as it's not a true .EXE.
3. Multiple versions of Office on the same PC.
4. Lack of 3rd party controls because Access does not fully implement the
IDispatch interface.
5. Lack of control over the main Access window.

as more of a pain because there's no real good solution for any of them
expect #3 (sage) and still be an Access Developer.

I suppose one thing beyond that which makes life really painful is the
automatic save of a main record when you move into a sub form control.

I'd have to say out of all the things taking Access "as is" and using it
the way that it's was intended to be used, that one causes the most
problems.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 19, 2014 12:08 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Most common problems/situations

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

-- 
Arthur
-- 


From fuller.artful at gmail.com  Wed Aug 20 00:00:02 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 20 Aug 2014 01:00:02 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <5355E6C4CCFE4345835997902CBF58C3@SteveT540p>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<E4DD19F21FFE45F5BB1636EC79F381CC@XPS>
	<5355E6C4CCFE4345835997902CBF58C3@SteveT540p>
Message-ID: <CAEPJO1g-cHe5Rhzj-AP712vywf0os8Mu+yhDkgtbwFfmscoTkw@mail.gmail.com>

Excellent additions to my list of problems with development using Access as
the development/deployment vehicle. As opposed to "Bucket List", I'm
calling this my "Bitch List".

A.


On Wed, Aug 20, 2014 at 12:24 AM, Steve Schapel <
steve at datamanagementsolutions.biz> wrote:

> That's interesting, Jim.  I have never thought of the "automatic save of a
> main record when you move into a sub form control" as a problem.  Could you
> say a little more about how this causes pain?  Thanks.
>
> Regards
> Steve
>
>
> -----Original Message----- From: Jim Dettman
> Sent: Wednesday, August 20, 2014 1:03 PM
>
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Most common problems/situations
>
> Not sure what the goal is here, but I see these:
>
> 1. Inability to do a 3tier design.
> 2. VBA references/"runtime environment" as it's not a true .EXE.
> 3. Multiple versions of Office on the same PC.
> 4. Lack of 3rd party controls because Access does not fully implement the
> IDispatch interface.
> 5. Lack of control over the main Access window.
>
> as more of a pain because there's no real good solution for any of them
> expect #3 (sage) and still be an Access Developer.
>
> I suppose one thing beyond that which makes life really painful is the
> automatic save of a main record when you move into a sub form control.
>
> I'd have to say out of all the things taking Access "as is" and using it
> the way that it's was intended to be used, that one causes the most
> problems.
>
> Jim.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 19, 2014 12:08 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Most common problems/situations
>
> I'm trying to gather a list of the most common problems and situations
> faced by an Access developer (strictly referring to design/coding/form
> types/control types/classes, etc., and leaving aside problems such as
> time-and-billing, getting paid in a timely fashion, how to factor into your
> billing rate the depreciation on your hardware and software investments,
> etc.).
>
> The initial ones that come to mind are:
> - Input masks
> - Master/Detail forms (could be nested, as in
> Customers/Orders/OrderDetails)
> - Combo boxes (also involves Cascading Combos and NotInList behaviour)
> - List boxes (also involves NotInList behaviour)
> - Linked forms (a pair of forms; navigation on either causes navigation on
> the other)
> - Office Integration (links to Excel, Word, Outlook,etc.)
> - Custom Nav buttons (assuming you don't like those built-in)
> - On-the-fly creation of new forms/dialogs/reports
> - Search and Filter facilities
> - Reports scoped to either the current row, or criteria
> - API calls
> - Export current record/report to PDF and email same
> - (Advanced) Creation of custom classes, most commonly custom controls
>
> These are the common problems I have commonly faced and addressed. Do you
> have others to add to this list? Eagerly seeking addition to this list.
>
> --
> Arthur
> --
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur

From gustav at cactus.dk  Wed Aug 20 02:08:28 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Wed, 20 Aug 2014 07:08:28 +0000
Subject: [AccessD] Most common problems/situations
Message-ID: <cc282a7a42514c7fa6ef0c4f2d3bf059@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Jim

True? I would say not taking and not using ...

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Jim Dettman
Sendt: 20. august 2014 03:04
Til: 'Access Developers discussion and problem solving'
Emne: Re: [AccessD] Most common problems/situations

I'd have to say out of all the things taking Access "as is" and using it the way that it's was intended to be used, that one causes the most problems. 


From bradm at blackforestltd.com  Wed Aug 20 10:48:18 2014
From: bradm at blackforestltd.com (Brad Marks)
Date: Wed, 20 Aug 2014 15:48:18 +0000
Subject: [AccessD] Gantt Charts via Access 2007
In-Reply-To: <006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
	<002401cfbc13$15742f10$405c8d30$@net>
	<006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>
Message-ID: <9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>

All,

Our VP of Operations has asked if we could create Gantt charts with Microsoft Access. 

We currently use Access 2007 to create many reports based on data that is stored in our manufacturing system (Firebird Database).

We also employ "Windows Automation" in order to control Excel from Access.

I am curious as to what options are available for the creation of Gantt Charts.

Excel?

Additional software?

Other options?

Thanks,
Brad  



From jackandpat.d at gmail.com  Wed Aug 20 11:25:03 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Wed, 20 Aug 2014 12:25:03 -0400
Subject: [AccessD] Gantt Charts via Access 2007
In-Reply-To: <9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
	<002401cfbc13$15742f10$405c8d30$@net>
	<006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>
	<9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>
Message-ID: <CAKvidAvsHSg6Vzd_gJQXkjQunOcba_SJqcdf18vDC=SQ1Ka+GQ@mail.gmail.com>

Brad,

No practical experience but I found a few links via Google (which you may
have already).

http://www.brighthub.com/computing/windows-platform/articles/57933.aspx

Excel: https://www.youtube.com/watch?v=NrfOtqzz_wk

Peter Hibbs has an Outlook style calendar in this thread
www.utteraccess.com/forum/Calendar-control-Access-t1956160.html   post #2
and there is a sample in post #9

Good luck.


On Wed, Aug 20, 2014 at 11:48 AM, Brad Marks <bradm at blackforestltd.com>
wrote:

> All,
>
> Our VP of Operations has asked if we could create Gantt charts with
> Microsoft Access.
>
> We currently use Access 2007 to create many reports based on data that is
> stored in our manufacturing system (Firebird Database).
>
> We also employ "Windows Automation" in order to control Excel from Access.
>
> I am curious as to what options are available for the creation of Gantt
> Charts.
>
> Excel?
>
> Additional software?
>
> Other options?
>
> Thanks,
> Brad
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From jackandpat.d at gmail.com  Wed Aug 20 11:26:30 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Wed, 20 Aug 2014 12:26:30 -0400
Subject: [AccessD] Gantt Charts via Access 2007
In-Reply-To: <CAKvidAvsHSg6Vzd_gJQXkjQunOcba_SJqcdf18vDC=SQ1Ka+GQ@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>
	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>
	<002401cfbc13$15742f10$405c8d30$@net>
	<006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>
	<9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>
	<CAKvidAvsHSg6Vzd_gJQXkjQunOcba_SJqcdf18vDC=SQ1Ka+GQ@mail.gmail.com>
Message-ID: <CAKvidAuqxE9tmTyH2PvjpBUy6S_7sW=wCLGBbs6z3RLQR8EgWw@mail.gmail.com>

Brad,

Just saw this also
http://www.utteraccess.com/forum/Schedule-Grid-t1333094.html


On Wed, Aug 20, 2014 at 12:25 PM, jack drawbridge <jackandpat.d at gmail.com>
wrote:

> Brad,
>
> No practical experience but I found a few links via Google (which you may
> have already).
>
> http://www.brighthub.com/computing/windows-platform/articles/57933.aspx
>
> Excel: https://www.youtube.com/watch?v=NrfOtqzz_wk
>
> Peter Hibbs has an Outlook style calendar in this thread
> www.utteraccess.com/forum/Calendar-control-Access-t1956160.html   post #2
> and there is a sample in post #9
>
> Good luck.
>
>
> On Wed, Aug 20, 2014 at 11:48 AM, Brad Marks <bradm at blackforestltd.com>
> wrote:
>
>> All,
>>
>> Our VP of Operations has asked if we could create Gantt charts with
>> Microsoft Access.
>>
>> We currently use Access 2007 to create many reports based on data that is
>> stored in our manufacturing system (Firebird Database).
>>
>> We also employ "Windows Automation" in order to control Excel from Access.
>>
>> I am curious as to what options are available for the creation of Gantt
>> Charts.
>>
>> Excel?
>>
>> Additional software?
>>
>> Other options?
>>
>> Thanks,
>> Brad
>>
>>
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>

From jamesbutton at blueyonder.co.uk  Wed Aug 20 11:31:24 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Wed, 20 Aug 2014 17:31:24 +0100
Subject: [AccessD] Gantt Charts via Access 2007
In-Reply-To: <CAKvidAuqxE9tmTyH2PvjpBUy6S_7sW=wCLGBbs6z3RLQR8EgWw@mail.gmail.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>	<002401cfbc13$15742f10$405c8d30$@net>	<006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>	<9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>	<CAKvidAvsHSg6Vzd_gJQXkjQunOcba_SJqcdf18vDC=SQ1Ka+GQ@mail.gmail.com>
	<CAKvidAuqxE9tmTyH2PvjpBUy6S_7sW=wCLGBbs6z3RLQR8EgWw@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAPHpCeSH/CtNlNd1Oz8OA/gBAAAAAA==@blueyonder.co.uk>

Maybe keywords of "Stacked barchart" will give some help.
Although it may be better to go for a project management package that allows you
to  'publish reports' under the main user licence.

JimB  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
Sent: Wednesday, August 20, 2014 5:27 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Gantt Charts via Access 2007

Brad,

Just saw this also
http://www.utteraccess.com/forum/Schedule-Grid-t1333094.html


On Wed, Aug 20, 2014 at 12:25 PM, jack drawbridge <jackandpat.d at gmail.com>
wrote:

> Brad,
>
> No practical experience but I found a few links via Google (which you may
> have already).
>
> http://www.brighthub.com/computing/windows-platform/articles/57933.aspx
>
> Excel: https://www.youtube.com/watch?v=NrfOtqzz_wk
>
> Peter Hibbs has an Outlook style calendar in this thread
> www.utteraccess.com/forum/Calendar-control-Access-t1956160.html   post #2
> and there is a sample in post #9
>
> Good luck.
>
>
> On Wed, Aug 20, 2014 at 11:48 AM, Brad Marks <bradm at blackforestltd.com>
> wrote:
>
>> All,
>>
>> Our VP of Operations has asked if we could create Gantt charts with
>> Microsoft Access.
>>
>> We currently use Access 2007 to create many reports based on data that is
>> stored in our manufacturing system (Firebird Database).
>>
>> We also employ "Windows Automation" in order to control Excel from Access.
>>
>> I am curious as to what options are available for the creation of Gantt
>> Charts.
>>
>> Excel?
>>
>> Additional software?
>>
>> Other options?
>>
>> Thanks,
>> Brad
>>
>>
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jimdettman at verizon.net  Wed Aug 20 12:34:37 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Wed, 20 Aug 2014 13:34:37 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <5355E6C4CCFE4345835997902CBF58C3@SteveT540p>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<E4DD19F21FFE45F5BB1636EC79F381CC@XPS>
	<5355E6C4CCFE4345835997902CBF58C3@SteveT540p>
Message-ID: <9DAA0E2BA05E48649188765CC013358A@XPS>

Steve,

  It's an issue for several reasons.  

  First, it's not at all obvious to a user that there are separate forms,
who instead sees the interface as a single form.  They expect it to work as
a complete unit.

  So the first problem you get is the expectation to be able to cancel/undo
and have everything disappear.  That doesn't happen.  Navigation is also not
intuitive; I tab / back tab for moving through the main form, but when I hit
a sub form, I need to use Ctrl/Tab to move into it.

  Second problem is the main form events Before Update, After Update, and
After Insert are all fired.  That makes doing main level logic difficult.
For example, if I want to ensure that a order is saved with at least one
line item to be considered valid, I can't easily do that. How do I tell when
their really moving off a main record vs just jumping into a sub form?
There's also the processing delay when I move off the main form into a sub
form, which is un-expected to the user.

  Any errors in the main form record also need to be handled.   Nothing more
confusing to a user than moving into a sub form, and getting a bunch of
errors.   The question always is "Why is it doing that now?  I'm not
finished yet."

  Third thing is that I've actually committed the record to the DB.  Let's
take a sequential invoice number; I've either had to use one and can't give
it back, or I had to save a record without assigning one.  Either of those
is not attractive.   And if a user decides they want to cancel, I now need
to go back and delete the main record.

  In general, it usually means you resort to temp tables and moving data
around in order to get a good interface, but that has issues to.

 I never realized how much of a chore main /sub form combinations in Access
were until I used VFP.   In VFP, you can elect to use several different
buffering modes and one of those is to buffer things until you explicitly
commit, which makes parent / child forms very easy to do and quite painless.

 Access came close to that when they finally allowed you to bind a record
set in code to a form (meaning you could use transactions), but it doesn't
quite work the way it should.   And of course you could go the fully unbound
route, but if your doing that, then why use Access at all.

Jim.
  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Wednesday, August 20, 2014 12:24 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Most common problems/situations

That's interesting, Jim.  I have never thought of the "automatic save of a 
main record when you move into a sub form control" as a problem.  Could you 
say a little more about how this causes pain?  Thanks.

Regards
Steve


-----Original Message----- 
From: Jim Dettman
Sent: Wednesday, August 20, 2014 1:03 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Most common problems/situations

Not sure what the goal is here, but I see these:

1. Inability to do a 3tier design.
2. VBA references/"runtime environment" as it's not a true .EXE.
3. Multiple versions of Office on the same PC.
4. Lack of 3rd party controls because Access does not fully implement the
IDispatch interface.
5. Lack of control over the main Access window.

as more of a pain because there's no real good solution for any of them
expect #3 (sage) and still be an Access Developer.

I suppose one thing beyond that which makes life really painful is the
automatic save of a main record when you move into a sub form control.

I'd have to say out of all the things taking Access "as is" and using it
the way that it's was intended to be used, that one causes the most
problems.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, August 19, 2014 12:08 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Most common problems/situations

I'm trying to gather a list of the most common problems and situations
faced by an Access developer (strictly referring to design/coding/form
types/control types/classes, etc., and leaving aside problems such as
time-and-billing, getting paid in a timely fashion, how to factor into your
billing rate the depreciation on your hardware and software investments,
etc.).

The initial ones that come to mind are:
- Input masks
- Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails)
- Combo boxes (also involves Cascading Combos and NotInList behaviour)
- List boxes (also involves NotInList behaviour)
- Linked forms (a pair of forms; navigation on either causes navigation on
the other)
- Office Integration (links to Excel, Word, Outlook,etc.)
- Custom Nav buttons (assuming you don't like those built-in)
- On-the-fly creation of new forms/dialogs/reports
- Search and Filter facilities
- Reports scoped to either the current row, or criteria
- API calls
- Export current record/report to PDF and email same
- (Advanced) Creation of custom classes, most commonly custom controls

These are the common problems I have commonly faced and addressed. Do you
have others to add to this list? Eagerly seeking addition to this list.

-- 
Arthur
-- 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From df.waters at outlook.com  Wed Aug 20 13:07:06 2014
From: df.waters at outlook.com (Dan Waters)
Date: Wed, 20 Aug 2014 13:07:06 -0500
Subject: [AccessD] Gantt Charts via Access 2007
In-Reply-To: <9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHs+q3UBiH1LoBubY0tzpScBAAAAAA==@blueyonder.co.uk>	<CAEPJO1i5ud+D8dCoY_aHNkNTacpQ8ea1tUJeBuK2xXPG5pYnAg@mail.gmail.com>	<002401cfbc13$15742f10$405c8d30$@net>	<006701cfbc1a$d12a0fc0$737e2f40$@gmail.com>
	<9c6952961b884b218fb07378f33790db@BLUPR0501MB884.namprd05.prod.outlook.com>
Message-ID: <BLU176-DS807B2AF163FF2F85F5312F6D20@phx.gbl>

Hi Brad,

Instead of trying to do this in Access, which would truly be reinventing the
wheel, there are Project applications which do just fine.  Of course, there
is MS Project, which costs $522 for one stand-alone license for the Standard
version.  

However, TurboProject Standard can be purchased for $90
(http://www.imsidesign.com/Products/Other-Products/TurboProject/TurboProject
-v4).  I used this long ago and it did everything that I needed as far as
Gannt charts went.

Another alternative might be GanttProject (http://www.ganttproject.biz/).
It appears to be free!

One important feature of any application that handles projects (gannt
charts, pert charts, etc.) is that it must export files which support MS
Project formats.  Eventually someone who uses MS Project will want to import
your project file.

HTH!
Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
Sent: Wednesday, August 20, 2014 10:48 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Gantt Charts via Access 2007

All,

Our VP of Operations has asked if we could create Gantt charts with
Microsoft Access. 

We currently use Access 2007 to create many reports based on data that is
stored in our manufacturing system (Firebird Database).

We also employ "Windows Automation" in order to control Excel from Access.

I am curious as to what options are available for the creation of Gantt
Charts.

Excel?

Additional software?

Other options?

Thanks,
Brad  


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jackandpat.d at gmail.com  Thu Aug 21 07:29:52 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Thu, 21 Aug 2014 08:29:52 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <9DAA0E2BA05E48649188765CC013358A@XPS>
References: <CAEPJO1g0s-_BKfKyaRLgNitwKcRnE6zjDms6mRGcX=j3KT4HeQ@mail.gmail.com>
	<E4DD19F21FFE45F5BB1636EC79F381CC@XPS>
	<5355E6C4CCFE4345835997902CBF58C3@SteveT540p>
	<9DAA0E2BA05E48649188765CC013358A@XPS>
Message-ID: <CAKvidAv8XJrasakvr930umu2jZDQkdVMhxEHevM-4QAf1Q-LzQ@mail.gmail.com>

Arthur,

Thought I'd pass this on since it came by today and seems to fit your
request.

" In the user interface - forms, query criteria, - where users enter dates,
MS assumes the format is the system setting, even if the date is enclosed
in # tags, as it might be in query criteria. I have always been led to
believe that any date between # marks had to be MDY (regardless of system
setting), but no. Only sometimes.

You'd think MS could enable users to set the date format that Access uses
everywhere, including SQL and VBA, regardless of the system date format
setting.

I wonder how many non-USA users have been caught by this, without realizing
it? "


On Wed, Aug 20, 2014 at 1:34 PM, Jim Dettman <jimdettman at verizon.net> wrote:

> Steve,
>
>   It's an issue for several reasons.
>
>   First, it's not at all obvious to a user that there are separate forms,
> who instead sees the interface as a single form.  They expect it to work as
> a complete unit.
>
>   So the first problem you get is the expectation to be able to cancel/undo
> and have everything disappear.  That doesn't happen.  Navigation is also
> not
> intuitive; I tab / back tab for moving through the main form, but when I
> hit
> a sub form, I need to use Ctrl/Tab to move into it.
>
>   Second problem is the main form events Before Update, After Update, and
> After Insert are all fired.  That makes doing main level logic difficult.
> For example, if I want to ensure that a order is saved with at least one
> line item to be considered valid, I can't easily do that. How do I tell
> when
> their really moving off a main record vs just jumping into a sub form?
> There's also the processing delay when I move off the main form into a sub
> form, which is un-expected to the user.
>
>   Any errors in the main form record also need to be handled.   Nothing
> more
> confusing to a user than moving into a sub form, and getting a bunch of
> errors.   The question always is "Why is it doing that now?  I'm not
> finished yet."
>
>   Third thing is that I've actually committed the record to the DB.  Let's
> take a sequential invoice number; I've either had to use one and can't give
> it back, or I had to save a record without assigning one.  Either of those
> is not attractive.   And if a user decides they want to cancel, I now need
> to go back and delete the main record.
>
>   In general, it usually means you resort to temp tables and moving data
> around in order to get a good interface, but that has issues to.
>
>  I never realized how much of a chore main /sub form combinations in Access
> were until I used VFP.   In VFP, you can elect to use several different
> buffering modes and one of those is to buffer things until you explicitly
> commit, which makes parent / child forms very easy to do and quite
> painless.
>
>  Access came close to that when they finally allowed you to bind a record
> set in code to a form (meaning you could use transactions), but it doesn't
> quite work the way it should.   And of course you could go the fully
> unbound
> route, but if your doing that, then why use Access at all.
>
> Jim.
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
> Sent: Wednesday, August 20, 2014 12:24 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Most common problems/situations
>
> That's interesting, Jim.  I have never thought of the "automatic save of a
> main record when you move into a sub form control" as a problem.  Could you
> say a little more about how this causes pain?  Thanks.
>
> Regards
> Steve
>
>
> -----Original Message-----
> From: Jim Dettman
> Sent: Wednesday, August 20, 2014 1:03 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Most common problems/situations
>
> Not sure what the goal is here, but I see these:
>
> 1. Inability to do a 3tier design.
> 2. VBA references/"runtime environment" as it's not a true .EXE.
> 3. Multiple versions of Office on the same PC.
> 4. Lack of 3rd party controls because Access does not fully implement the
> IDispatch interface.
> 5. Lack of control over the main Access window.
>
> as more of a pain because there's no real good solution for any of them
> expect #3 (sage) and still be an Access Developer.
>
> I suppose one thing beyond that which makes life really painful is the
> automatic save of a main record when you move into a sub form control.
>
> I'd have to say out of all the things taking Access "as is" and using it
> the way that it's was intended to be used, that one causes the most
> problems.
>
> Jim.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Tuesday, August 19, 2014 12:08 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Most common problems/situations
>
> I'm trying to gather a list of the most common problems and situations
> faced by an Access developer (strictly referring to design/coding/form
> types/control types/classes, etc., and leaving aside problems such as
> time-and-billing, getting paid in a timely fashion, how to factor into your
> billing rate the depreciation on your hardware and software investments,
> etc.).
>
> The initial ones that come to mind are:
> - Input masks
> - Master/Detail forms (could be nested, as in
> Customers/Orders/OrderDetails)
> - Combo boxes (also involves Cascading Combos and NotInList behaviour)
> - List boxes (also involves NotInList behaviour)
> - Linked forms (a pair of forms; navigation on either causes navigation on
> the other)
> - Office Integration (links to Excel, Word, Outlook,etc.)
> - Custom Nav buttons (assuming you don't like those built-in)
> - On-the-fly creation of new forms/dialogs/reports
> - Search and Filter facilities
> - Reports scoped to either the current row, or criteria
> - API calls
> - Export current record/report to PDF and email same
> - (Advanced) Creation of custom classes, most commonly custom controls
>
> These are the common problems I have commonly faced and addressed. Do you
> have others to add to this list? Eagerly seeking addition to this list.
>
> --
> Arthur
> --
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From gustav at cactus.dk  Thu Aug 21 08:23:20 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Thu, 21 Aug 2014 13:23:20 +0000
Subject: [AccessD] Most common problems/situations
Message-ID: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Jack

There is no "sometimes". In the GUI, the date format is always localized except if you specify another format in the Format property.
In VBA and SQL, date string expressions are always read in US, then local, then ISO format until a match. 
For CDate and DateValue, however, the sequence is local, US, ISO.
For ADO and FindFirst, only the ISO format is reliable.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
Sendt: 21. august 2014 14:30
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Most common problems/situations

Arthur,

Thought I'd pass this on since it came by today and seems to fit your request.

" In the user interface - forms, query criteria, - where users enter dates, MS assumes the format is the system setting, even if the date is enclosed in # tags, as it might be in query criteria. I have always been led to believe that any date between # marks had to be MDY (regardless of system setting), but no. Only sometimes.

You'd think MS could enable users to set the date format that Access uses everywhere, including SQL and VBA, regardless of the system date format setting.

I wonder how many non-USA users have been caught by this, without realizing it? "


From jackandpat.d at gmail.com  Thu Aug 21 08:52:13 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Thu, 21 Aug 2014 09:52:13 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CAKvidAuEokmhBuC8pVYP4ym5mTJsTvVLVkqMBAcdLivs4+d3iQ@mail.gmail.com>

Gustav,

Thanks for the clarification.
I was passing on some experiences/comments from a user/developer and this
article by Allen Browne. <http://allenbrowne.com/ser-36.html>

jack


On Thu, Aug 21, 2014 at 9:23 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Jack
>
> There is no "sometimes". In the GUI, the date format is always localized
> except if you specify another format in the Format property.
> In VBA and SQL, date string expressions are always read in US, then local,
> then ISO format until a match.
> For CDate and DateValue, however, the sequence is local, US, ISO.
> For ADO and FindFirst, only the ISO format is reliable.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> Sendt: 21. august 2014 14:30
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Most common problems/situations
>
> Arthur,
>
> Thought I'd pass this on since it came by today and seems to fit your
> request.
>
> " In the user interface - forms, query criteria, - where users enter
> dates, MS assumes the format is the system setting, even if the date is
> enclosed in # tags, as it might be in query criteria. I have always been
> led to believe that any date between # marks had to be MDY (regardless of
> system setting), but no. Only sometimes.
>
> You'd think MS could enable users to set the date format that Access uses
> everywhere, including SQL and VBA, regardless of the system date format
> setting.
>
> I wonder how many non-USA users have been caught by this, without
> realizing it? "
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From gustav at cactus.dk  Thu Aug 21 09:12:41 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Thu, 21 Aug 2014 14:12:41 +0000
Subject: [AccessD] Most common problems/situations
Message-ID: <9f5a11b423c34f668ceeb00c06c839d5@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Jack

Yes, I have seen that page. I think it somewhat scares the user, though the rules are quite simple. Focus should be on how to do it right rather than what can goes wrong (because it, of course, most likely will fail if you don't follow the rules).

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
Sendt: 21. august 2014 15:52
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Most common problems/situations

Gustav,

Thanks for the clarification.
I was passing on some experiences/comments from a user/developer and this article by Allen Browne. <http://allenbrowne.com/ser-36.html>

jack


On Thu, Aug 21, 2014 at 9:23 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Jack
>
> There is no "sometimes". In the GUI, the date format is always 
> localized except if you specify another format in the Format property.
> In VBA and SQL, date string expressions are always read in US, then 
> local, then ISO format until a match.
> For CDate and DateValue, however, the sequence is local, US, ISO.
> For ADO and FindFirst, only the ISO format is reliable.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> Sendt: 21. august 2014 14:30
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Most common problems/situations
>
> Arthur,
>
> Thought I'd pass this on since it came by today and seems to fit your 
> request.
>
> " In the user interface - forms, query criteria, - where users enter 
> dates, MS assumes the format is the system setting, even if the date 
> is enclosed in # tags, as it might be in query criteria. I have always 
> been led to believe that any date between # marks had to be MDY 
> (regardless of system setting), but no. Only sometimes.
>
> You'd think MS could enable users to set the date format that Access 
> uses everywhere, including SQL and VBA, regardless of the system date 
> format setting.
>
> I wonder how many non-USA users have been caught by this, without 
> realizing it? " 



From bensonforums at gmail.com  Thu Aug 21 09:35:31 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 10:35:31 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CAJLzs_0qCtCNjRwTR3BD-u5vKZ16dY3OWqG-wO6k1rBSkLmjrA@mail.gmail.com>

I have always worked in US so I don't think I have ever run into this. But,
if there is SQL looking for 08/04/2014 and in the data there is no
08/04/2014, but there happens to be a 04/08/2014, and the user's local date
format is Europe, will a match on  04/08/2014 be returned? What would the
workaround be if your US database BE has an Access FE being used in
European environment?
On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:

> Hi Jack
>
> There is no "sometimes". In the GUI, the date format is always localized
> except if you specify another format in the Format property.
> In VBA and SQL, date string expressions are always read in US, then local,
> then ISO format until a match.
> For CDate and DateValue, however, the sequence is local, US, ISO.
> For ADO and FindFirst, only the ISO format is reliable.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> Sendt: 21. august 2014 14:30
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Most common problems/situations
>
> Arthur,
>
> Thought I'd pass this on since it came by today and seems to fit your
> request.
>
> " In the user interface - forms, query criteria, - where users enter
> dates, MS assumes the format is the system setting, even if the date is
> enclosed in # tags, as it might be in query criteria. I have always been
> led to believe that any date between # marks had to be MDY (regardless of
> system setting), but no. Only sometimes.
>
> You'd think MS could enable users to set the date format that Access uses
> everywhere, including SQL and VBA, regardless of the system date format
> setting.
>
> I wonder how many non-USA users have been caught by this, without
> realizing it? "
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From gustav at cactus.dk  Thu Aug 21 09:40:27 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Thu, 21 Aug 2014 14:40:27 +0000
Subject: [AccessD] Most common problems/situations
In-Reply-To: <CAJLzs_0qCtCNjRwTR3BD-u5vKZ16dY3OWqG-wO6k1rBSkLmjrA@mail.gmail.com>
References: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
	<CAJLzs_0qCtCNjRwTR3BD-u5vKZ16dY3OWqG-wO6k1rBSkLmjrA@mail.gmail.com>
Message-ID: <807f877164e04ed8a2bf653ac9b6b2b2@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Bill

The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
It will never fail.

As for the GUI, it never fails as long as you follow the simple rules mentioned.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
Sendt: 21. august 2014 16:36
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Most common problems/situations

I have always worked in US so I don't think I have ever run into this. But, if there is SQL looking for 08/04/2014 and in the data there is no 08/04/2014, but there happens to be a 04/08/2014, and the user's local date format is Europe, will a match on  04/08/2014 be returned? What would the workaround be if your US database BE has an Access FE being used in European environment?
On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:

> Hi Jack
>
> There is no "sometimes". In the GUI, the date format is always 
> localized except if you specify another format in the Format property.
> In VBA and SQL, date string expressions are always read in US, then 
> local, then ISO format until a match.
> For CDate and DateValue, however, the sequence is local, US, ISO.
> For ADO and FindFirst, only the ISO format is reliable.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> Sendt: 21. august 2014 14:30
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Most common problems/situations
>
> Arthur,
>
> Thought I'd pass this on since it came by today and seems to fit your 
> request.
>
> " In the user interface - forms, query criteria, - where users enter 
> dates, MS assumes the format is the system setting, even if the date 
> is enclosed in # tags, as it might be in query criteria. I have always 
> been led to believe that any date between # marks had to be MDY 
> (regardless of system setting), but no. Only sometimes.
>
> You'd think MS could enable users to set the date format that Access 
> uses everywhere, including SQL and VBA, regardless of the system date 
> format setting.
>
> I wonder how many non-USA users have been caught by this, without 
> realizing it? " 


From bensonforums at gmail.com  Thu Aug 21 09:50:02 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 10:50:02 -0400
Subject: [AccessD] Most common problems/situations
In-Reply-To: <807f877164e04ed8a2bf653ac9b6b2b2@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <6d79de59e62b4b2bbd23da63b0470d34@AMSPR06MB357.eurprd06.prod.outlook.com>
	<CAJLzs_0qCtCNjRwTR3BD-u5vKZ16dY3OWqG-wO6k1rBSkLmjrA@mail.gmail.com>
	<807f877164e04ed8a2bf653ac9b6b2b2@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CAJLzs_0R2RVh=uq6S=PggpbDvhGdK=ZyGxNMAnQh=YJFe0xndQ@mail.gmail.com>

Thanks, I never format dates like that in access sql, now I will be sure
to. I think I format them that way for oracle, of necessity.
On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:

> Hi Bill
>
> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
> It will never fail.
>
> As for the GUI, it never fails as long as you follow the simple rules
> mentioned.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> Sendt: 21. august 2014 16:36
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Most common problems/situations
>
> I have always worked in US so I don't think I have ever run into this.
> But, if there is SQL looking for 08/04/2014 and in the data there is no
> 08/04/2014, but there happens to be a 04/08/2014, and the user's local date
> format is Europe, will a match on  04/08/2014 be returned? What would the
> workaround be if your US database BE has an Access FE being used in
> European environment?
> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>
> > Hi Jack
> >
> > There is no "sometimes". In the GUI, the date format is always
> > localized except if you specify another format in the Format property.
> > In VBA and SQL, date string expressions are always read in US, then
> > local, then ISO format until a match.
> > For CDate and DateValue, however, the sequence is local, US, ISO.
> > For ADO and FindFirst, only the ISO format is reliable.
> >
> > /gustav
> >
> > -----Oprindelig meddelelse-----
> > Fra: accessd-bounces at databaseadvisors.com [mailto:
> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> > Sendt: 21. august 2014 14:30
> > Til: Access Developers discussion and problem solving
> > Emne: Re: [AccessD] Most common problems/situations
> >
> > Arthur,
> >
> > Thought I'd pass this on since it came by today and seems to fit your
> > request.
> >
> > " In the user interface - forms, query criteria, - where users enter
> > dates, MS assumes the format is the system setting, even if the date
> > is enclosed in # tags, as it might be in query criteria. I have always
> > been led to believe that any date between # marks had to be MDY
> > (regardless of system setting), but no. Only sometimes.
> >
> > You'd think MS could enable users to set the date format that Access
> > uses everywhere, including SQL and VBA, regardless of the system date
> > format setting.
> >
> > I wonder how many non-USA users have been caught by this, without
> > realizing it? "
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From bensonforums at gmail.com  Thu Aug 21 10:12:52 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 11:12:52 -0400
Subject: [AccessD] New thrd: dates
Message-ID: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>

Please forgive my lack of experience, also I thought since this is a deeper
discussion on dates I would retain some but not all of the former posts.

GUI. What is meant by GUI date? Is this a bound textbox reading a date from
the back end?

Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local
environment with no local formatting, would that display as
04/08/2014 In Europe?

Now supposed unbound forms (which are what primarily work with)

If I populate a text box with

TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")

And the max date in the table is 08/10/2014, what will show in the local
(Europe) text box?, I assume based on what has been said, 10/08/2014, no?

If suppose I have another text box called TxtEffective_dt.  The user wants
to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or
12/08/14.

When I take that value to enter it into the database (remember backend is
US) would I write

Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"

Or
Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"

Or something else that will have to convert the text property of
txteffectivedate to the US format?

>
> On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> Hi Bill
>>
>> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
>> It will never fail.
>>
>> As for the GUI, it never fails as long as you follow the simple rules
mentioned.
>>
>> /gustav
>>
>> -----Oprindelig meddelelse-----
>> Fra: accessd-bounces at databaseadvisors.com [mailto:
accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
>> Sendt: 21. august 2014 16:36
>> Til: Access Developers discussion and problem solving
>> Emne: Re: [AccessD] Most common problems/situations
>>
>> I have always worked in US so I don't think I have ever run into this.
But, if there is SQL looking for 08/04/2014 and in the data there is no
08/04/2014, but there happens to be a 04/08/2014, and the user's local date
format is Europe, will a match on  04/08/2014 be returned? What would the
workaround be if your US database BE has an Access FE being used in
European environment?
>> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> > Hi Jack
>> >
>> > There is no "sometimes". In the GUI, the date format is always
>> > localized except if you specify another format in the Format property.
>> > In VBA and SQL, date string expressions are always read in US, then
>> > local, then ISO format until a match.
>> > For CDate and DateValue, however, the sequence is local, US, ISO.
>> > For ADO and FindFirst, only the ISO format is reliable.
>> >
>> > /gustav
>> >
>> > -----Oprindelig meddelelse-----
>> > Fra: accessd-bounces at databaseadvisors.com [mailto:
>> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
>> > Sendt: 21. august 2014 14:30
>> > Til: Access Developers discussion and problem solving
>> > Emne: Re: [AccessD] Most common problems/situations
>> >
>> > Arthur,
>> >
>> > Thought I'd pass this on since it came by today and seems to fit your
>> > request.
>> >
>> > " In the user interface - forms, query criteria, - where users enter
>> > dates, MS assumes the format is the system setting, even if the date
>> > is enclosed in # tags, as it might be in query criteria. I have always
>> > been led to believe that any date between # marks had to be MDY
>> > (regardless of system setting), but no. Only sometimes.
>> >
>> > You'd think MS could enable users to set the date format that Access
>> > uses everywhere, including SQL and VBA, regardless of the system date
>> > format setting.
>> >
>> > I wonder how many non-USA users have been caught by this, without
>> > realizing it? "
>>

From jamesbutton at blueyonder.co.uk  Thu Aug 21 11:27:48 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Thu, 21 Aug 2014 17:27:48 +0100
Subject: [AccessD] New thrd: dates
In-Reply-To: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAK94tx+UFaVBlIfSjH5mtIEBAAAAAA==@blueyonder.co.uk>

I'd expect a reference to a GUI means graphical User interface - as in a form or other form of data presentation/input display that is not at 'programmer test-data file/table level)
-------------------------------------------
Your example 
Aug 4th 2014 stored as 08/04/2014.
Is it actually stored as the string "08/04/2014"

As in 
Oracle stores DATE in total of 7 bytes. Each byte in it stores values for an element of the DATE as follows:
Byte Description 
1 Century value but before storing it add 100 to it 
2 Year and 100 is added to it before storing 
3 Month 
4 Day of the month 
5 Hours but add 1 before storing it 
6 Minutes but add 1 before storing it 
7 Seconds but add 1 before storing it

Access stores Date/Times internally stored as an 8 byte double precision floating point numbers.
So the range is virtually unlimited. (Dates up to 2 million AD can be stored with a precision of 1 second.) MDB Viewer exports dates in the format YYYY-MM-DD HH:MM:SS.
--------------------------------------------

The problem should not be in dealing with date(time) values in a database as that should - Ha! SHOULD have been validated on input.
And presumably (! again) have been stored using the DBMS's  internal date (day number) format.

Adopt 'standards' (and ask the client what standards they prefer if the ones you have are not acceptable.)
As in 
Display dates with 4 digit years, and the month in alpha (3 char - or if you are really tight on space - 2 char), which also allows you to lose separators.  If possible use a calendar to allow the user to select the date - avoids any (! Again) confusion on the part of the user.
If you cannot use a calendar selection for input, then require the date to be entered with month as a 3 letter alpha (using the set for the country) and validate that, converting it to the internal storage - as in specifically using the US/ISO format.
Or if you cannot constrain them to alpha month, display the entered date using the alpha month

As far as searching data in the DBMS - that should, if it is to be held as a date,  be in the internal format, so as long as you are specific in the definition of the date you are specifying to be found, there should be no problem.

Then there are the things like invoices - where you want the actual entry as shown, and do not want the system to convert the reference code of "01/02" or "01/02/14", or "01/02/2014" into dates, and then - later someone decides they want to search for invoices with a specific reference and they assume it was a date.
Even more fun invoices 1 to 5 of a set for ongoing action, shown with 1/5/  2/5/  3/5/  etc. as prefix's to the reference number.

It's fun out there in commerce and industry !

JimB


-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Thursday, August 21, 2014 4:13 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] New thrd: dates

Please forgive my lack of experience, also I thought since this is a deeper
discussion on dates I would retain some but not all of the former posts.

GUI. What is meant by GUI date? Is this a bound textbox reading a date from
the back end?

Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local
environment with no local formatting, would that display as
04/08/2014 In Europe?

Now supposed unbound forms (which are what primarily work with)

If I populate a text box with

TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")

And the max date in the table is 08/10/2014, what will show in the local
(Europe) text box?, I assume based on what has been said, 10/08/2014, no?

If suppose I have another text box called TxtEffective_dt.  The user wants
to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or
12/08/14.

When I take that value to enter it into the database (remember backend is
US) would I write

Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"

Or
Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"

Or something else that will have to convert the text property of
txteffectivedate to the US format?

>
> On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> Hi Bill
>>
>> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
>> It will never fail.
>>
>> As for the GUI, it never fails as long as you follow the simple rules
mentioned.
>>
>> /gustav
>>
>> -----Oprindelig meddelelse-----
>> Fra: accessd-bounces at databaseadvisors.com [mailto:
accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
>> Sendt: 21. august 2014 16:36
>> Til: Access Developers discussion and problem solving
>> Emne: Re: [AccessD] Most common problems/situations
>>
>> I have always worked in US so I don't think I have ever run into this.
But, if there is SQL looking for 08/04/2014 and in the data there is no
08/04/2014, but there happens to be a 04/08/2014, and the user's local date
format is Europe, will a match on  04/08/2014 be returned? What would the
workaround be if your US database BE has an Access FE being used in
European environment?
>> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> > Hi Jack
>> >
>> > There is no "sometimes". In the GUI, the date format is always
>> > localized except if you specify another format in the Format property.
>> > In VBA and SQL, date string expressions are always read in US, then
>> > local, then ISO format until a match.
>> > For CDate and DateValue, however, the sequence is local, US, ISO.
>> > For ADO and FindFirst, only the ISO format is reliable.
>> >
>> > /gustav
>> >
>> > -----Oprindelig meddelelse-----
>> > Fra: accessd-bounces at databaseadvisors.com [mailto:
>> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
>> > Sendt: 21. august 2014 14:30
>> > Til: Access Developers discussion and problem solving
>> > Emne: Re: [AccessD] Most common problems/situations
>> >
>> > Arthur,
>> >
>> > Thought I'd pass this on since it came by today and seems to fit your
>> > request.
>> >
>> > " In the user interface - forms, query criteria, - where users enter
>> > dates, MS assumes the format is the system setting, even if the date
>> > is enclosed in # tags, as it might be in query criteria. I have always
>> > been led to believe that any date between # marks had to be MDY
>> > (regardless of system setting), but no. Only sometimes.
>> >
>> > You'd think MS could enable users to set the date format that Access
>> > uses everywhere, including SQL and VBA, regardless of the system date
>> > format setting.
>> >
>> > I wonder how many non-USA users have been caught by this, without
>> > realizing it? "
>>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From davidmcafee at gmail.com  Thu Aug 21 12:17:57 2014
From: davidmcafee at gmail.com (David McAfee)
Date: Thu, 21 Aug 2014 10:17:57 -0700
Subject: [AccessD] Pasting into Excel
Message-ID: <CAMhYZWbrzFoGSNkRgNXg4P-GzRHj8-kAaR4Q+uV1oOkjmgbT2w@mail.gmail.com>

I know this question should really go to Excel-L rather than Access-D, but
you're all a smart bunch so I figured I'd ask here first. ;)


A pet peeve of mine is pasting data from and Access Query or SQL Server
Management Studio into Excel and the data is wrapped and dates always show
up weird.

I don't remember this occurring before Office 2007 (but I can't remember
past last weekend much less 7 years ago).

So every time I paste a big grid of data, I have to toggle "wrap text"
three times.

If I choose "Short Date" from the formatting drop down in the number
toolbar (in the ribbon) the dates will change to short dates.

If I past the same (or different) data from the clip board it reverts back,
losing the short data and non wrapped text formatting.

Am I silly to think it didn't work this way in earlier versions?

Thanks,
David

From jamesbutton at blueyonder.co.uk  Thu Aug 21 12:49:32 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Thu, 21 Aug 2014 18:49:32 +0100
Subject: [AccessD] Pasting into Excel
In-Reply-To: <CAMhYZWbrzFoGSNkRgNXg4P-GzRHj8-kAaR4Q+uV1oOkjmgbT2w@mail.gmail.com>
References: <CAMhYZWbrzFoGSNkRgNXg4P-GzRHj8-kAaR4Q+uV1oOkjmgbT2w@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAALO/MfT9vuVEhL3yUGedPRUBAAAAAA==@blueyonder.co.uk>

Consider that Paste includes some (not all) of the formatting - either actual as
in where Excel recognises dates (well, thinks? It has).
There is paste Special values that will not (well probably not) change the
formatting of cells.

Re dates - you will need to consider the data being posted (as in what is its
format) 
The country code of the OS, the country code of Excel, the defaults set, and
what format is specified for the cells getting the data.

AFAIK Excel  sets Wrap if it finds a newline in the text string

Now you mention Excel 2007, but do not explicitly state what version you are
using, or what OS, which could also have some effect on the clipboard handling.

Re your question: 
No! It's MS software!

JimB  
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee
Sent: Thursday, August 21, 2014 6:18 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Pasting into Excel

I know this question should really go to Excel-L rather than Access-D, but
you're all a smart bunch so I figured I'd ask here first. ;)


A pet peeve of mine is pasting data from and Access Query or SQL Server
Management Studio into Excel and the data is wrapped and dates always show
up weird.

I don't remember this occurring before Office 2007 (but I can't remember
past last weekend much less 7 years ago).

So every time I paste a big grid of data, I have to toggle "wrap text"
three times.

If I choose "Short Date" from the formatting drop down in the number
toolbar (in the ribbon) the dates will change to short dates.

If I past the same (or different) data from the clip board it reverts back,
losing the short data and non wrapped text formatting.

Am I silly to think it didn't work this way in earlier versions?

Thanks,
David
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Thu Aug 21 12:58:14 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 13:58:14 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAK94tx+UFaVBlIfSjH5mtIEBAAAAAA==@blueyonder.co.uk>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAK94tx+UFaVBlIfSjH5mtIEBAAAAAA==@blueyonder.co.uk>
Message-ID: <CAJLzs_0Af-6aATZ0mtVeH5ga6W5X2LSN0PjjQ22tAkjKMfTjGg@mail.gmail.com>

Too much for me to understand, sorry. If my examples were simple perhaps an
direct answer based on my examples would be helpful. If my examples were
not clear, I could try to restate. All that verbiage about standards should
be irrelevant as I am asking what Access will do natively based on a
backend sitting on a US server and a FE running in a European office which
is attached across a network.
On Aug 21, 2014 12:30 PM, "James Button" <jamesbutton at blueyonder.co.uk>
wrote:

> I'd expect a reference to a GUI means graphical User interface - as in a
> form or other form of data presentation/input display that is not at
> 'programmer test-data file/table level)
> -------------------------------------------
> Your example
> Aug 4th 2014 stored as 08/04/2014.
> Is it actually stored as the string "08/04/2014"
>
> As in
> Oracle stores DATE in total of 7 bytes. Each byte in it stores values for
> an element of the DATE as follows:
> Byte Description
> 1 Century value but before storing it add 100 to it
> 2 Year and 100 is added to it before storing
> 3 Month
> 4 Day of the month
> 5 Hours but add 1 before storing it
> 6 Minutes but add 1 before storing it
> 7 Seconds but add 1 before storing it
>
> Access stores Date/Times internally stored as an 8 byte double precision
> floating point numbers.
> So the range is virtually unlimited. (Dates up to 2 million AD can be
> stored with a precision of 1 second.) MDB Viewer exports dates in the
> format YYYY-MM-DD HH:MM:SS.
> --------------------------------------------
>
> The problem should not be in dealing with date(time) values in a database
> as that should - Ha! SHOULD have been validated on input.
> And presumably (! again) have been stored using the DBMS's  internal date
> (day number) format.
>
> Adopt 'standards' (and ask the client what standards they prefer if the
> ones you have are not acceptable.)
> As in
> Display dates with 4 digit years, and the month in alpha (3 char - or if
> you are really tight on space - 2 char), which also allows you to lose
> separators.  If possible use a calendar to allow the user to select the
> date - avoids any (! Again) confusion on the part of the user.
> If you cannot use a calendar selection for input, then require the date to
> be entered with month as a 3 letter alpha (using the set for the country)
> and validate that, converting it to the internal storage - as in
> specifically using the US/ISO format.
> Or if you cannot constrain them to alpha month, display the entered date
> using the alpha month
>
> As far as searching data in the DBMS - that should, if it is to be held as
> a date,  be in the internal format, so as long as you are specific in the
> definition of the date you are specifying to be found, there should be no
> problem.
>
> Then there are the things like invoices - where you want the actual entry
> as shown, and do not want the system to convert the reference code of
> "01/02" or "01/02/14", or "01/02/2014" into dates, and then - later someone
> decides they want to search for invoices with a specific reference and they
> assume it was a date.
> Even more fun invoices 1 to 5 of a set for ongoing action, shown with
> 1/5/  2/5/  3/5/  etc. as prefix's to the reference number.
>
> It's fun out there in commerce and industry !
>
> JimB
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
> Sent: Thursday, August 21, 2014 4:13 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] New thrd: dates
>
> Please forgive my lack of experience, also I thought since this is a deeper
> discussion on dates I would retain some but not all of the former posts.
>
> GUI. What is meant by GUI date? Is this a bound textbox reading a date from
> the back end?
>
> Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local
> environment with no local formatting, would that display as
> 04/08/2014 In Europe?
>
> Now supposed unbound forms (which are what primarily work with)
>
> If I populate a text box with
>
> TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")
>
> And the max date in the table is 08/10/2014, what will show in the local
> (Europe) text box?, I assume based on what has been said, 10/08/2014, no?
>
> If suppose I have another text box called TxtEffective_dt.  The user wants
> to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or
> 12/08/14.
>
> When I take that value to enter it into the database (remember backend is
> US) would I write
>
> Sql = "Insert into myTable (name, address, effective_dt) values ('" &
> txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
>
> Or
> Sql = "Insert into myTable (name, address, effective_dt) values ('" &
> txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"
>
> Or something else that will have to convert the text property of
> txteffectivedate to the US format?
>
> >
> > On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> Hi Bill
> >>
> >> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
> >> It will never fail.
> >>
> >> As for the GUI, it never fails as long as you follow the simple rules
> mentioned.
> >>
> >> /gustav
> >>
> >> -----Oprindelig meddelelse-----
> >> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> >> Sendt: 21. august 2014 16:36
> >> Til: Access Developers discussion and problem solving
> >> Emne: Re: [AccessD] Most common problems/situations
> >>
> >> I have always worked in US so I don't think I have ever run into this.
> But, if there is SQL looking for 08/04/2014 and in the data there is no
> 08/04/2014, but there happens to be a 04/08/2014, and the user's local date
> format is Europe, will a match on  04/08/2014 be returned? What would the
> workaround be if your US database BE has an Access FE being used in
> European environment?
> >> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> > Hi Jack
> >> >
> >> > There is no "sometimes". In the GUI, the date format is always
> >> > localized except if you specify another format in the Format property.
> >> > In VBA and SQL, date string expressions are always read in US, then
> >> > local, then ISO format until a match.
> >> > For CDate and DateValue, however, the sequence is local, US, ISO.
> >> > For ADO and FindFirst, only the ISO format is reliable.
> >> >
> >> > /gustav
> >> >
> >> > -----Oprindelig meddelelse-----
> >> > Fra: accessd-bounces at databaseadvisors.com [mailto:
> >> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> >> > Sendt: 21. august 2014 14:30
> >> > Til: Access Developers discussion and problem solving
> >> > Emne: Re: [AccessD] Most common problems/situations
> >> >
> >> > Arthur,
> >> >
> >> > Thought I'd pass this on since it came by today and seems to fit your
> >> > request.
> >> >
> >> > " In the user interface - forms, query criteria, - where users enter
> >> > dates, MS assumes the format is the system setting, even if the date
> >> > is enclosed in # tags, as it might be in query criteria. I have always
> >> > been led to believe that any date between # marks had to be MDY
> >> > (regardless of system setting), but no. Only sometimes.
> >> >
> >> > You'd think MS could enable users to set the date format that Access
> >> > uses everywhere, including SQL and VBA, regardless of the system date
> >> > format setting.
> >> >
> >> > I wonder how many non-USA users have been caught by this, without
> >> > realizing it? "
> >>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From jamesbutton at blueyonder.co.uk  Thu Aug 21 13:58:08 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Thu, 21 Aug 2014 19:58:08 +0100
Subject: [AccessD] New thrd: dates
In-Reply-To: <CAJLzs_0Af-6aATZ0mtVeH5ga6W5X2LSN0PjjQ22tAkjKMfTjGg@mail.gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAK94tx+UFaVBlIfSjH5mtIEBAAAAAA==@blueyonder.co.uk>
	<CAJLzs_0Af-6aATZ0mtVeH5ga6W5X2LSN0PjjQ22tAkjKMfTjGg@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>

Bill,

GUI would be the FE application 'page/window display' facility.
Effect would depend on:
1) the format the data is put into by the BE, - probably determined by the OS, DBMS, and data extraction application being used.
2) The OS and application being used to select/request the data and then print/present it to the user/viewer 
3) If the data is held as a date by the DBMS then it will be in an internal format without any display characteristics such as 4 digit year, month or day first whatever.
(the verbiage - but there is the possibility that the dates are held as test strings rather than as Access Dates.)

So the submission of selection criteria and data presentation will be according to the implicit definitions in the client PC OS and application setup, modified by the defaults associated by the particular versions of the OS & application, unless specifically conditioned by your handling, and format specification of the data.


Re 
#" & txteffectivedate & "#)"
#" & cdate(txteffectivedate) & "#)"

If that is 'submitted' as a text query to a USA DBMS, expect to enter the values in MM/DD/YYYY format
When data is returned it could be as the internal format, but is more likely to be in the format assumed by the BE - as in USA  MM/DD/YYYY format.

A simple test such as  (>#10/01/2104# and  <#08/02/2104#) and then (>#08/02/2104# and <#10/01/2104#) should let you know what the setup is doing/using as the format.
Otherwise, sorry but in an unspecified environment it is not possible to give a specific answer.
It could be that the FE is itself a DBMS and is actually handling the data doing selection from a view of the USA based data

In other words - It depends on your setup !

JimB   
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Thursday, August 21, 2014 6:58 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

Too much for me to understand, sorry. If my examples were simple perhaps an
direct answer based on my examples would be helpful. If my examples were
not clear, I could try to restate. All that verbiage about standards should
be irrelevant as I am asking what Access will do natively based on a
backend sitting on a US server and a FE running in a European office which
is attached across a network.
On Aug 21, 2014 12:30 PM, "James Button" <jamesbutton at blueyonder.co.uk>
wrote:

> I'd expect a reference to a GUI means graphical User interface - as in a
> form or other form of data presentation/input display that is not at
> 'programmer test-data file/table level)
> -------------------------------------------
> Your example
> Aug 4th 2014 stored as 08/04/2014.
> Is it actually stored as the string "08/04/2014"
>
> As in
> Oracle stores DATE in total of 7 bytes. Each byte in it stores values for
> an element of the DATE as follows:
> Byte Description
> 1 Century value but before storing it add 100 to it
> 2 Year and 100 is added to it before storing
> 3 Month
> 4 Day of the month
> 5 Hours but add 1 before storing it
> 6 Minutes but add 1 before storing it
> 7 Seconds but add 1 before storing it
>
> Access stores Date/Times internally stored as an 8 byte double precision
> floating point numbers.
> So the range is virtually unlimited. (Dates up to 2 million AD can be
> stored with a precision of 1 second.) MDB Viewer exports dates in the
> format YYYY-MM-DD HH:MM:SS.
> --------------------------------------------
>
> The problem should not be in dealing with date(time) values in a database
> as that should - Ha! SHOULD have been validated on input.
> And presumably (! again) have been stored using the DBMS's  internal date
> (day number) format.
>
> Adopt 'standards' (and ask the client what standards they prefer if the
> ones you have are not acceptable.)
> As in
> Display dates with 4 digit years, and the month in alpha (3 char - or if
> you are really tight on space - 2 char), which also allows you to lose
> separators.  If possible use a calendar to allow the user to select the
> date - avoids any (! Again) confusion on the part of the user.
> If you cannot use a calendar selection for input, then require the date to
> be entered with month as a 3 letter alpha (using the set for the country)
> and validate that, converting it to the internal storage - as in
> specifically using the US/ISO format.
> Or if you cannot constrain them to alpha month, display the entered date
> using the alpha month
>
> As far as searching data in the DBMS - that should, if it is to be held as
> a date,  be in the internal format, so as long as you are specific in the
> definition of the date you are specifying to be found, there should be no
> problem.
>
> Then there are the things like invoices - where you want the actual entry
> as shown, and do not want the system to convert the reference code of
> "01/02" or "01/02/14", or "01/02/2014" into dates, and then - later someone
> decides they want to search for invoices with a specific reference and they
> assume it was a date.
> Even more fun invoices 1 to 5 of a set for ongoing action, shown with
> 1/5/  2/5/  3/5/  etc. as prefix's to the reference number.
>
> It's fun out there in commerce and industry !
>
> JimB
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
> Sent: Thursday, August 21, 2014 4:13 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] New thrd: dates
>
> Please forgive my lack of experience, also I thought since this is a deeper
> discussion on dates I would retain some but not all of the former posts.
>
> GUI. What is meant by GUI date? Is this a bound textbox reading a date from
> the back end?
>
> Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local
> environment with no local formatting, would that display as
> 04/08/2014 In Europe?
>
> Now supposed unbound forms (which are what primarily work with)
>
> If I populate a text box with
>
> TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")
>
> And the max date in the table is 08/10/2014, what will show in the local
> (Europe) text box?, I assume based on what has been said, 10/08/2014, no?
>
> If suppose I have another text box called TxtEffective_dt.  The user wants
> to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or
> 12/08/14.
>
> When I take that value to enter it into the database (remember backend is
> US) would I write
>
> Sql = "Insert into myTable (name, address, effective_dt) values ('" &
> txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
>
> Or
> Sql = "Insert into myTable (name, address, effective_dt) values ('" &
> txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"
>
> Or something else that will have to convert the text property of
> txteffectivedate to the US format?
>
> >
> > On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> Hi Bill
> >>
> >> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
> >> It will never fail.
> >>
> >> As for the GUI, it never fails as long as you follow the simple rules
> mentioned.
> >>
> >> /gustav
> >>
> >> -----Oprindelig meddelelse-----
> >> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> >> Sendt: 21. august 2014 16:36
> >> Til: Access Developers discussion and problem solving
> >> Emne: Re: [AccessD] Most common problems/situations
> >>
> >> I have always worked in US so I don't think I have ever run into this.
> But, if there is SQL looking for 08/04/2014 and in the data there is no
> 08/04/2014, but there happens to be a 04/08/2014, and the user's local date
> format is Europe, will a match on  04/08/2014 be returned? What would the
> workaround be if your US database BE has an Access FE being used in
> European environment?
> >> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> > Hi Jack
> >> >
> >> > There is no "sometimes". In the GUI, the date format is always
> >> > localized except if you specify another format in the Format property.
> >> > In VBA and SQL, date string expressions are always read in US, then
> >> > local, then ISO format until a match.
> >> > For CDate and DateValue, however, the sequence is local, US, ISO.
> >> > For ADO and FindFirst, only the ISO format is reliable.
> >> >
> >> > /gustav
> >> >
> >> > -----Oprindelig meddelelse-----
> >> > Fra: accessd-bounces at databaseadvisors.com [mailto:
> >> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> >> > Sendt: 21. august 2014 14:30
> >> > Til: Access Developers discussion and problem solving
> >> > Emne: Re: [AccessD] Most common problems/situations
> >> >
> >> > Arthur,
> >> >
> >> > Thought I'd pass this on since it came by today and seems to fit your
> >> > request.
> >> >
> >> > " In the user interface - forms, query criteria, - where users enter
> >> > dates, MS assumes the format is the system setting, even if the date
> >> > is enclosed in # tags, as it might be in query criteria. I have always
> >> > been led to believe that any date between # marks had to be MDY
> >> > (regardless of system setting), but no. Only sometimes.
> >> >
> >> > You'd think MS could enable users to set the date format that Access
> >> > uses everywhere, including SQL and VBA, regardless of the system date
> >> > format setting.
> >> >
> >> > I wonder how many non-USA users have been caught by this, without
> >> > realizing it? "
> >>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From bensonforums at gmail.com  Thu Aug 21 14:46:03 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 15:46:03 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAK94tx+UFaVBlIfSjH5mtIEBAAAAAA==@blueyonder.co.uk>	<CAJLzs_0Af-6aATZ0mtVeH5ga6W5X2LSN0PjjQ22tAkjKMfTjGg@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>
Message-ID: <043d01cfbd78$8b1d1d60$a1575820$@gmail.com>

I am really sorry I asked this one now! My question "what is meant by a GUI date just needed a yes or no to my illustration, to wit, " Is this a bound textbox reading a date from the back end?"; [or if not that, something else - and if so, what?].

Jim said: 
<<GUI would be the FE application 'page/window display' facility.
I don't know what that is. I have never heard of anything so technical in answer to what I thought was a simple question, and that is why, if there are no other answers out there, I withdraw the question.

Jim further said the effect would depend on
<<1) the format the data is put into by the BE 
I already posted:
<<my backend had Aug 4th 2014 stored as 08/04/2014
As I was discussing an Access only solution, I think I pretty much covered that this is an Access Date stored as 08/04/2014.
I cannot see how I could be clearer.

Jim paraphrases my lengthier question regarding SQL statements that incorporate the "#" delimiter and a direct reading of the value (as opposed to the text property) of
	txtEffectivedate as

Re
#" & txteffectivedate & "#)"
#" & cdate(txteffectivedate) & "#)"


I had written (*emphasis* added):
> When *I take that value* to enter it into the database (remember backend 
> is
> US) would I write
>
> Sql = "Insert into myTable (name, address, effective_dt) values ('" & 
> txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"

> Or
> Sql = "Insert into myTable (name, address, effective_dt) values ('" & 
> txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"

I don't feel Jim has given me an answer and I am asking again for someone in this List to give a yes to one (and if so, which), yes to either, no to both (and if so, what is the right way).
Reason:  Jim ventures: 
<<If that is 'submitted' as a text query to a USA DBMS, expect to enter the values in MM/DD/YYYY format

I am not asking about a pass through query, so I don't know what the BE has to do with it. I am talking about DoCmd.RunSQL or CurrentDB.Execute and the like. Again, this Front End is a running European instance of MS Access and Interface. I am going to continue to assume that the FE is driving the inquiry, althout it continues to be unclear to me what the "value" really is at any point in time. This is new information being put into a record, and I believe that the back-end will have a different idea of what is meant by 04/08/2014 than the front-end will.

I cannot test this (though testing it would certainly be very simple if I had the right environment) because I don't have a European Front End to test it with. I guess I will not worry about it for the foreseeable future.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button
Sent: Thursday, August 21, 2014 2:58 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] New thrd: dates

Bill,

GUI would be the FE application 'page/window display' facility.
Effect would depend on:
1) the format the data is put into by the BE, - probably determined by the OS, DBMS, and data extraction application being used.
2) The OS and application being used to select/request the data and then print/present it to the user/viewer
3) If the data is held as a date by the DBMS then it will be in an internal format without any display characteristics such as 4 digit year, month or day first whatever.
(the verbiage - but there is the possibility that the dates are held as test strings rather than as Access Dates.)

So the submission of selection criteria and data presentation will be according to the implicit definitions in the client PC OS and application setup, modified by the defaults associated by the particular versions of the OS & application, unless specifically conditioned by your handling, and format specification of the data.


Re
#" & txteffectivedate & "#)"
#" & cdate(txteffectivedate) & "#)"

If that is 'submitted' as a text query to a USA DBMS, expect to enter the values in MM/DD/YYYY format When data is returned it could be as the internal format, but is more likely to be in the format assumed by the BE - as in USA  MM/DD/YYYY format.

A simple test such as  (>#10/01/2104# and  <#08/02/2104#) and then (>#08/02/2104# and <#10/01/2104#) should let you know what the setup is doing/using as the format.
Otherwise, sorry but in an unspecified environment it is not possible to give a specific answer.
It could be that the FE is itself a DBMS and is actually handling the data doing selection from a view of the USA based data

In other words - It depends on your setup !

JimB   
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Thursday, August 21, 2014 6:58 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

Too much for me to understand, sorry. If my examples were simple perhaps an direct answer based on my examples would be helpful. If my examples were not clear, I could try to restate. All that verbiage about standards should be irrelevant as I am asking what Access will do natively based on a backend sitting on a US server and a FE running in a European office which is attached across a network.
On Aug 21, 2014 12:30 PM, "James Button" <jamesbutton at blueyonder.co.uk>
wrote:

> I'd expect a reference to a GUI means graphical User interface - as in 
> a form or other form of data presentation/input display that is not at 
> 'programmer test-data file/table level)
> -------------------------------------------
> Your example
> Aug 4th 2014 stored as 08/04/2014.
> Is it actually stored as the string "08/04/2014"
>
> As in
> Oracle stores DATE in total of 7 bytes. Each byte in it stores values 
> for an element of the DATE as follows:
> Byte Description
> 1 Century value but before storing it add 100 to it
> 2 Year and 100 is added to it before storing
> 3 Month
> 4 Day of the month
> 5 Hours but add 1 before storing it
> 6 Minutes but add 1 before storing it
> 7 Seconds but add 1 before storing it
>
> Access stores Date/Times internally stored as an 8 byte double 
> precision floating point numbers.
> So the range is virtually unlimited. (Dates up to 2 million AD can be 
> stored with a precision of 1 second.) MDB Viewer exports dates in the 
> format YYYY-MM-DD HH:MM:SS.
> --------------------------------------------
>
> The problem should not be in dealing with date(time) values in a 
> database as that should - Ha! SHOULD have been validated on input.
> And presumably (! again) have been stored using the DBMS's  internal 
> date (day number) format.
>
> Adopt 'standards' (and ask the client what standards they prefer if 
> the ones you have are not acceptable.) As in Display dates with 4 
> digit years, and the month in alpha (3 char - or if you are really 
> tight on space - 2 char), which also allows you to lose separators.  
> If possible use a calendar to allow the user to select the date - 
> avoids any (! Again) confusion on the part of the user.
> If you cannot use a calendar selection for input, then require the 
> date to be entered with month as a 3 letter alpha (using the set for 
> the country) and validate that, converting it to the internal storage 
> - as in specifically using the US/ISO format.
> Or if you cannot constrain them to alpha month, display the entered 
> date using the alpha month
>
> As far as searching data in the DBMS - that should, if it is to be 
> held as a date,  be in the internal format, so as long as you are 
> specific in the definition of the date you are specifying to be found, 
> there should be no problem.
>
> Then there are the things like invoices - where you want the actual 
> entry as shown, and do not want the system to convert the reference 
> code of "01/02" or "01/02/14", or "01/02/2014" into dates, and then - 
> later someone decides they want to search for invoices with a specific 
> reference and they assume it was a date.
> Even more fun invoices 1 to 5 of a set for ongoing action, shown with 
> 1/5/  2/5/  3/5/  etc. as prefix's to the reference number.
>
> It's fun out there in commerce and industry !
>
> JimB
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
> Sent: Thursday, August 21, 2014 4:13 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] New thrd: dates
>
> Please forgive my lack of experience, also I thought since this is a 
> deeper discussion on dates I would retain some but not all of the former posts.
>
> GUI. What is meant by GUI date? Is this a bound textbox reading a date 
> from the back end?
>
> Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the 
> local environment with no local formatting, would that display as
> 04/08/2014 In Europe?
>
> Now supposed unbound forms (which are what primarily work with)
>
> If I populate a text box with
>
> TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")
>
> And the max date in the table is 08/10/2014, what will show in the 
> local
> (Europe) text box?, I assume based on what has been said, 10/08/2014, no?
>
> If suppose I have another text box called TxtEffective_dt.  The user 
> wants to enter Aug 12th, 2014 so thwy, being in Europe, enter 
> 12/08/2014 or 12/08/14.
>
> When I take that value to enter it into the database (remember backend 
> is
> US) would I write
>
> Sql = "Insert into myTable (name, address, effective_dt) values ('" & 
> txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
>
> Or
> Sql = "Insert into myTable (name, address, effective_dt) values ('" & 
> txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"
>
> Or something else that will have to convert the text property of 
> txteffectivedate to the US format?
>
> >
> > On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> Hi Bill
> >>
> >> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
> >> It will never fail.
> >>
> >> As for the GUI, it never fails as long as you follow the simple 
> >> rules
> mentioned.
> >>
> >> /gustav
> >>
> >> -----Oprindelig meddelelse-----
> >> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> >> Sendt: 21. august 2014 16:36
> >> Til: Access Developers discussion and problem solving
> >> Emne: Re: [AccessD] Most common problems/situations
> >>
> >> I have always worked in US so I don't think I have ever run into this.
> But, if there is SQL looking for 08/04/2014 and in the data there is 
> no 08/04/2014, but there happens to be a 04/08/2014, and the user's 
> local date format is Europe, will a match on  04/08/2014 be returned? 
> What would the workaround be if your US database BE has an Access FE 
> being used in European environment?
> >> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
> >>
> >> > Hi Jack
> >> >
> >> > There is no "sometimes". In the GUI, the date format is always 
> >> > localized except if you specify another format in the Format property.
> >> > In VBA and SQL, date string expressions are always read in US, 
> >> > then local, then ISO format until a match.
> >> > For CDate and DateValue, however, the sequence is local, US, ISO.
> >> > For ADO and FindFirst, only the ISO format is reliable.
> >> >
> >> > /gustav
> >> >
> >> > -----Oprindelig meddelelse-----
> >> > Fra: accessd-bounces at databaseadvisors.com [mailto:
> >> > accessd-bounces at databaseadvisors.com] P? vegne af jack drawbridge
> >> > Sendt: 21. august 2014 14:30
> >> > Til: Access Developers discussion and problem solving
> >> > Emne: Re: [AccessD] Most common problems/situations
> >> >
> >> > Arthur,
> >> >
> >> > Thought I'd pass this on since it came by today and seems to fit 
> >> > your request.
> >> >
> >> > " In the user interface - forms, query criteria, - where users 
> >> > enter dates, MS assumes the format is the system setting, even if 
> >> > the date is enclosed in # tags, as it might be in query criteria. 
> >> > I have always been led to believe that any date between # marks 
> >> > had to be MDY (regardless of system setting), but no. Only sometimes.
> >> >
> >> > You'd think MS could enable users to set the date format that 
> >> > Access uses everywhere, including SQL and VBA, regardless of the 
> >> > system date format setting.
> >> >
> >> > I wonder how many non-USA users have been caught by this, without 
> >> > realizing it? "
> >>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From stuart at lexacorp.com.pg  Thu Aug 21 16:50:08 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 22 Aug 2014 07:50:08 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>,
	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
Message-ID: <53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>

OK, here goes as asked for (an Access FE/BE):

Answers in line.

On 21 Aug 2014 at 15:46, Bill Benson wrote:

> I am really sorry I asked this one now! My question "what is meant by
> a GUI date just needed a yes or no to my illustration, to wit, " Is
> this a bound textbox reading a date from the back end?"; [or if not
> that, something else - and if so, what?].
> 

Yes.   It's the formatted date as displayed in a control on a form or report.

> Jim further said the effect would depend on
> <<1) the format the data is put into by the BE 
> I already posted:
> <<my backend had Aug 4th 2014 stored as 08/04/2014

No, your date is NOT stored iin an Access BE as 08.04/02014.  It is stored as
the number 41855.0   which is the number of days since 30 Dec 1899.

> I had written (*emphasis* added):
> > When *I take that value* to enter it into the database (remember
> > backend is US) would I write
> >
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
> 
> > Or
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) &
> > "#)"

It doesn't matter whether the BE is US or UK, the date is stored as the same number.  

The problem is that the SQL engine in the Access FE requires a date surrounded by "#"s to 
be in a specific format, which may not be the format in which txtEffectiveDate is being 
displayed. (In a European FE, the txtEffectiveDate could be 08/04/2014, 04/08/2014,"04 Aug 
2014","Aug 4 2014" , "Auot 4 2014", or many other language specific formats.)       

There are two common solutions:

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"

or

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"',Datevalue('" & txteffectivedate & "'))"

FWIW, I always use the second version and have never had a problem with it.



From jamesbutton at blueyonder.co.uk  Thu Aug 21 17:28:47 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Thu, 21 Aug 2014 23:28:47 +0100
Subject: [AccessD] New thrd: dates
In-Reply-To: <53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>,
	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAACb7aF8aceZAichWDWamaegBAAAAAA==@blueyonder.co.uk>


Amongst the many posts on the web about dates this one may be appropriate to
this discussion - the pain to consider and avoid
http://allenbrowne.com/ser-36.html

and from MS - the options 
<https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us
/country.mspx?mfr=true>

There are probably a win8 and office 2013 365 etc. versions but that link was in
my histerical notes. 

JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Thursday, August 21, 2014 10:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

OK, here goes as asked for (an Access FE/BE):

Answers in line.

On 21 Aug 2014 at 15:46, Bill Benson wrote:

> I am really sorry I asked this one now! My question "what is meant by
> a GUI date just needed a yes or no to my illustration, to wit, " Is
> this a bound textbox reading a date from the back end?"; [or if not
> that, something else - and if so, what?].
> 

Yes.   It's the formatted date as displayed in a control on a form or report.

> Jim further said the effect would depend on
> <<1) the format the data is put into by the BE 
> I already posted:
> <<my backend had Aug 4th 2014 stored as 08/04/2014

No, your date is NOT stored iin an Access BE as 08.04/02014.  It is stored as
the number 41855.0   which is the number of days since 30 Dec 1899.

> I had written (*emphasis* added):
> > When *I take that value* to enter it into the database (remember
> > backend is US) would I write
> >
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
> 
> > Or
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) &
> > "#)"

It doesn't matter whether the BE is US or UK, the date is stored as the same
number.  

The problem is that the SQL engine in the Access FE requires a date surrounded
by "#"s to 
be in a specific format, which may not be the format in which txtEffectiveDate
is being 
displayed. (In a European FE, the txtEffectiveDate could be 08/04/2014,
04/08/2014,"04 Aug 
2014","Aug 4 2014" , "Auot 4 2014", or many other language specific formats.)


There are two common solutions:

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"

or

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"',Datevalue('" & txteffectivedate & "'))"

FWIW, I always use the second version and have never had a problem with it.


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jackandpat.d at gmail.com  Thu Aug 21 17:44:29 2014
From: jackandpat.d at gmail.com (jack drawbridge)
Date: Thu, 21 Aug 2014 18:44:29 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAACb7aF8aceZAichWDWamaegBAAAAAA==@blueyonder.co.uk>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>
	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAACb7aF8aceZAichWDWamaegBAAAAAA==@blueyonder.co.uk>
Message-ID: <CAKvidAvsPG0oMM4aJtum22BFZi93ydzqtcz0CrxhaTm6z4ya1g@mail.gmail.com>

James,

That's one of the pieces to which Gustav responded in the original thread.


jack


On Thu, Aug 21, 2014 at 6:28 PM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

>
> Amongst the many posts on the web about dates this one may be appropriate
> to
> this discussion - the pain to consider and avoid
> http://allenbrowne.com/ser-36.html
>
> and from MS - the options
> <
> https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us
> /country.mspx?mfr=true>
>
> There are probably a win8 and office 2013 365 etc. versions but that link
> was in
> my histerical notes.
>
> JimB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan
> Sent: Thursday, August 21, 2014 10:50 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] New thrd: dates
>
> OK, here goes as asked for (an Access FE/BE):
>
> Answers in line.
>
> On 21 Aug 2014 at 15:46, Bill Benson wrote:
>
> > I am really sorry I asked this one now! My question "what is meant by
> > a GUI date just needed a yes or no to my illustration, to wit, " Is
> > this a bound textbox reading a date from the back end?"; [or if not
> > that, something else - and if so, what?].
> >
>
> Yes.   It's the formatted date as displayed in a control on a form or
> report.
>
> > Jim further said the effect would depend on
> > <<1) the format the data is put into by the BE
> > I already posted:
> > <<my backend had Aug 4th 2014 stored as 08/04/2014
>
> No, your date is NOT stored iin an Access BE as 08.04/02014.  It is stored
> as
> the number 41855.0   which is the number of days since 30 Dec 1899.
>
> > I had written (*emphasis* added):
> > > When *I take that value* to enter it into the database (remember
> > > backend is US) would I write
> > >
> > > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > > & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
> >
> > > Or
> > > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > > & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) &
> > > "#)"
>
> It doesn't matter whether the BE is US or UK, the date is stored as the
> same
> number.
>
> The problem is that the SQL engine in the Access FE requires a date
> surrounded
> by "#"s to
> be in a specific format, which may not be the format in which
> txtEffectiveDate
> is being
> displayed. (In a European FE, the txtEffectiveDate could be 08/04/2014,
> 04/08/2014,"04 Aug
> 2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
> formats.)
>
>
> There are two common solutions:
>
>  Sql = "Insert into myTable (name, address, effective_dt) values ('"
>  & txtname & "','" & txtaddress & _
> "', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"
>
> or
>
>  Sql = "Insert into myTable (name, address, effective_dt) values ('"
>  & txtname & "','" & txtaddress & _
> "',Datevalue('" & txteffectivedate & "'))"
>
> FWIW, I always use the second version and have never had a problem with it.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From bensonforums at gmail.com  Thu Aug 21 18:06:02 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 21 Aug 2014 19:06:02 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>,
	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
Message-ID: <04ba01cfbd94$81aad620$85008260$@gmail.com>

Love - and am deeply grateful for, Stuart, the simplicity in your answer.
Loved even more "I always use" w/o problems, that means field tested. Any
reason you use DateValue rather than CDate?



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Thursday, August 21, 2014 5:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

OK, here goes as asked for (an Access FE/BE):

Answers in line.

On 21 Aug 2014 at 15:46, Bill Benson wrote:

> I am really sorry I asked this one now! My question "what is meant by 
> a GUI date just needed a yes or no to my illustration, to wit, " Is 
> this a bound textbox reading a date from the back end?"; [or if not 
> that, something else - and if so, what?].
> 

Yes.   It's the formatted date as displayed in a control on a form or
report.

> Jim further said the effect would depend on
> <<1) the format the data is put into by the BE I already posted:
> <<my backend had Aug 4th 2014 stored as 08/04/2014

No, your date is NOT stored iin an Access BE as 08.04/02014.  It is stored
as
the number 41855.0   which is the number of days since 30 Dec 1899.

> I had written (*emphasis* added):
> > When *I take that value* to enter it into the database (remember 
> > backend is US) would I write
> >
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
> 
> > Or
> > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & 
> > "#)"

It doesn't matter whether the BE is US or UK, the date is stored as the same
number.  

The problem is that the SQL engine in the Access FE requires a date
surrounded by "#"s to be in a specific format, which may not be the format
in which txtEffectiveDate is being displayed. (In a European FE, the
txtEffectiveDate could be 08/04/2014, 04/08/2014,"04 Aug 
2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
formats.)       

There are two common solutions:

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"

or

 Sql = "Insert into myTable (name, address, effective_dt) values ('"
 & txtname & "','" & txtaddress & _
"',Datevalue('" & txteffectivedate & "'))"

FWIW, I always use the second version and have never had a problem with it.


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Thu Aug 21 18:11:39 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 22 Aug 2014 00:11:39 +0100
Subject: [AccessD] New thrd: dates
In-Reply-To: <CAKvidAvsPG0oMM4aJtum22BFZi93ydzqtcz0CrxhaTm6z4ya1g@mail.gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAACb7aF8aceZAichWDWamaegBAAAAAA==@blueyonder.co.uk>
	<CAKvidAvsPG0oMM4aJtum22BFZi93ydzqtcz0CrxhaTm6z4ya1g@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAI+e0jBDnnRNmJ6SJsrz3hkBAAAAAA==@blueyonder.co.uk>

Jack, 

That's almost certainly where I got that reference - well it was over a day ago
that Gustav post it.

Gustav, thanks for the entry to keep in my notes - 

Bummer that my bio-memory store isn't keeping such a good sources index lately.

JimB  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jack drawbridge
Sent: Thursday, August 21, 2014 11:44 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

James,

That's one of the pieces to which Gustav responded in the original thread.


jack


On Thu, Aug 21, 2014 at 6:28 PM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

>
> Amongst the many posts on the web about dates this one may be appropriate
> to
> this discussion - the pain to consider and avoid
> http://allenbrowne.com/ser-36.html
>
> and from MS - the options
> <
>
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us
> /country.mspx?mfr=true>
>
> There are probably a win8 and office 2013 365 etc. versions but that link
> was in
> my histerical notes.
>
> JimB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan
> Sent: Thursday, August 21, 2014 10:50 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] New thrd: dates
>
> OK, here goes as asked for (an Access FE/BE):
>
> Answers in line.
>
> On 21 Aug 2014 at 15:46, Bill Benson wrote:
>
> > I am really sorry I asked this one now! My question "what is meant by
> > a GUI date just needed a yes or no to my illustration, to wit, " Is
> > this a bound textbox reading a date from the back end?"; [or if not
> > that, something else - and if so, what?].
> >
>
> Yes.   It's the formatted date as displayed in a control on a form or
> report.
>
> > Jim further said the effect would depend on
> > <<1) the format the data is put into by the BE
> > I already posted:
> > <<my backend had Aug 4th 2014 stored as 08/04/2014
>
> No, your date is NOT stored iin an Access BE as 08.04/02014.  It is stored
> as
> the number 41855.0   which is the number of days since 30 Dec 1899.
>
> > I had written (*emphasis* added):
> > > When *I take that value* to enter it into the database (remember
> > > backend is US) would I write
> > >
> > > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > > & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"
> >
> > > Or
> > > Sql = "Insert into myTable (name, address, effective_dt) values ('"
> > > & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) &
> > > "#)"
>
> It doesn't matter whether the BE is US or UK, the date is stored as the
> same
> number.
>
> The problem is that the SQL engine in the Access FE requires a date
> surrounded
> by "#"s to
> be in a specific format, which may not be the format in which
> txtEffectiveDate
> is being
> displayed. (In a European FE, the txtEffectiveDate could be 08/04/2014,
> 04/08/2014,"04 Aug
> 2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
> formats.)
>
>
> There are two common solutions:
>
>  Sql = "Insert into myTable (name, address, effective_dt) values ('"
>  & txtname & "','" & txtaddress & _
> "', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"
>
> or
>
>  Sql = "Insert into myTable (name, address, effective_dt) values ('"
>  & txtname & "','" & txtaddress & _
> "',Datevalue('" & txteffectivedate & "'))"
>
> FWIW, I always use the second version and have never had a problem with it.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Thu Aug 21 18:40:41 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 22 Aug 2014 09:40:41 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <04ba01cfbd94$81aad620$85008260$@gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>,
	<04ba01cfbd94$81aad620$85008260$@gmail.com>
Message-ID: <53F68379.4036.F7430003@stuart.lexacorp.com.pg>

No reason other than habit.  They both do exactly the same thing as far as I can tell.

On 21 Aug 2014 at 19:06, Bill Benson wrote:

> Love - and am deeply grateful for, Stuart, the simplicity in your
> answer. Loved even more "I always use" w/o problems, that means field
> tested. Any reason you use DateValue rather than CDate?
> 
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Thursday, August 21, 2014 5:50 PM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD] New
> thrd: dates
> 
> OK, here goes as asked for (an Access FE/BE):
> 
> Answers in line.
> 
> On 21 Aug 2014 at 15:46, Bill Benson wrote:
> 
> > I am really sorry I asked this one now! My question "what is meant
> > by a GUI date just needed a yes or no to my illustration, to wit, "
> > Is this a bound textbox reading a date from the back end?"; [or if
> > not that, something else - and if so, what?].
> > 
> 
> Yes.   It's the formatted date as displayed in a control on a form or
> report.
> 
> > Jim further said the effect would depend on
> > <<1) the format the data is put into by the BE I already posted:
> > <<my backend had Aug 4th 2014 stored as 08/04/2014
> 
> No, your date is NOT stored iin an Access BE as 08.04/02014.  It is
> stored as the number 41855.0   which is the number of days since 30
> Dec 1899.
> 
> > I had written (*emphasis* added):
> > > When *I take that value* to enter it into the database (remember
> > > backend is US) would I write
> > >
> > > Sql = "Insert into myTable (name, address, effective_dt) values
> > > ('" & txtname & "','" & txtaddress & "', #" & txteffectivedate &
> > > "#)"
> > 
> > > Or
> > > Sql = "Insert into myTable (name, address, effective_dt) values
> > > ('" & txtname & "','" & txtaddress & "', #" &
> > > cdate(txteffectivedate) & "#)"
> 
> It doesn't matter whether the BE is US or UK, the date is stored as
> the same number.  
> 
> The problem is that the SQL engine in the Access FE requires a date
> surrounded by "#"s to be in a specific format, which may not be the
> format in which txtEffectiveDate is being displayed. (In a European
> FE, the txtEffectiveDate could be 08/04/2014, 04/08/2014,"04 Aug
> 2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
> formats.)       
> 
> There are two common solutions:
> 
>  Sql = "Insert into myTable (name, address, effective_dt) values ('" &
>  txtname & "','" & txtaddress & _
> "', #" & format(txteffectivedate,"mm/dd/yyyy") & "#)"
> 
> or
> 
>  Sql = "Insert into myTable (name, address, effective_dt) values ('" &
>  txtname & "','" & txtaddress & _
> "',Datevalue('" & txteffectivedate & "'))"
> 
> FWIW, I always use the second version and have never had a problem
> with it.
> 
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From gustav at cactus.dk  Fri Aug 22 03:12:08 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Fri, 22 Aug 2014 08:12:08 +0000
Subject: [AccessD] New thrd: dates
Message-ID: <a7fa2ed6bef648c8967d6da7f8e03f6f@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Bill

GUI is the user interface which includes the graphic query designer.

Your questions are already answered by Stuart.

The difference between DateValue (and TimeValue) and CDate is that for a date/time expression, CDate will return the full date/time value while DateValue and TimeValue only returns a part of it.

In addition you have CVDate which - though labelled obsolete - works perfectly well and has the advantage over CDate that it accepts Null values (returning Null).

The great value of DateValue is that it reads a textbox using the local format as the first attempt. Thus a date like 2014-09-11 will here by default be displayed as 11-09-2014, and DateValue will read and convert this to the date/time value of 2014-09-11.

This is where much code fails. If you have a query with filtering on a textbox this way:

Select * From Table Where DateField = [Forms]![frmMyForm]![txtDate]

it will work if  you specify [Forms]![frmMyForm]![txtDate] as a parameter of data type Date (and the form is open).

But if you write SQL code like this:

strSQL = "Select * From Table Where DateField = #" & Me!txtDate & "#"

it will fail outside the US as it will result in:

Select * From Table Where DateField = #11-09-2014#

To solve this, the simple method shown by Stuart will work, though you should make it a habit to use the ISO sequence: 

strDate = Format(Me!txtDate, "yyyy\/mm\/dd")
strSQL = "Select * From Table Where DateField = #" & strDate & "#"

or, as Stuart mentions:

strSQL = "Select * From Table Where DateField = DateValue(" & Me!txtDate & ")"

You will often meet this falty construction which only shows a lack of understanding of the mechanics:

strSQL = "Select * From Table Where DateField = #" & CDate(Me!txtDate) & "#"

The reason it fails is, that even though CDate correctly converts the expression to a date/time value, this cannot be concatenated with the SQL string, thus Access has to cast it to a text expression. However, this will be done as to the local settings resulting (here) in 11-09-2014 where you would need 09-11-2014.

/gustav


-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
Sendt: 21. august 2014 17:13
Til: Access Developers discussion and problem solving
Emne: [AccessD] New thrd: dates

Please forgive my lack of experience, also I thought since this is a deeper discussion on dates I would retain some but not all of the former posts.

GUI. What is meant by GUI date? Is this a bound textbox reading a date from the back end?

Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local environment with no local formatting, would that display as
04/08/2014 In Europe?

Now supposed unbound forms (which are what primarily work with)

If I populate a text box with

TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")

And the max date in the table is 08/10/2014, what will show in the local
(Europe) text box?, I assume based on what has been said, 10/08/2014, no?

If suppose I have another text box called TxtEffective_dt.  The user wants to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or 12/08/14.

When I take that value to enter it into the database (remember backend is
US) would I write

Sql = "Insert into myTable (name, address, effective_dt) values ('" & txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"

Or
Sql = "Insert into myTable (name, address, effective_dt) values ('" & txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"

Or something else that will have to convert the text property of txteffectivedate to the US format?

>
> On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> Hi Bill
>>
>> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
>> It will never fail.
>>
>> As for the GUI, it never fails as long as you follow the simple rules mentioned.
>>
>> /gustav 


From stuart at lexacorp.com.pg  Fri Aug 22 03:59:28 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 22 Aug 2014 18:59:28 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <a7fa2ed6bef648c8967d6da7f8e03f6f@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <a7fa2ed6bef648c8967d6da7f8e03f6f@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <53F70670.1114.F9429808@stuart.lexacorp.com.pg>

The reason that CVDate can return a Null is that it returns a Variant of Type Date, the others 
return an actual  Date (numeric) value.  There are advantages and disadvantages to that.

On 22 Aug 2014 at 8:12, Gustav Brock wrote:

> 
> In addition you have CVDate which - though labelled obsolete - works
> perfectly well and has the advantage over CDate that it accepts Null
> values (returning Null).
> 


From bensonforums at gmail.com  Fri Aug 22 07:58:48 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 22 Aug 2014 08:58:48 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>
	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
Message-ID: <CAJLzs_3x6yP7HkN-sVB+H6sNaTjT-En0JY91FuZRahh34mUUiw@mail.gmail.com>

Love - and am deeply grateful for, Stuart, the simplicity in that answer.
And the best part were the words "I always use" - which shows this is
field tested.

As a side question, I assume you use simply now() when time stamping an
access date field on the FE or BE regardless of the location, but what
happens when performing a loop and you want to insert all records with no
possibility of time stamp variation, such that you hold a date in
A variable like

dtStamp= Now ()

Do

    Blah blah inserts record with dtStamp

Loop

Do you use any conversion functions or rely on dtStamp to be a number?

From gustav at cactus.dk  Fri Aug 22 08:09:21 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Fri, 22 Aug 2014 13:09:21 +0000
Subject: [AccessD] New thrd: dates
Message-ID: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Bill

You would rely on dtStamp being a date/time value. The field would be of data type Date.

The records would be stamped identically with the value of dtStamp.
If you want the real time as close as possible, for example in a loop of long duration in VBA, you would call Now within the loop for each insertion.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
Sendt: 22. august 2014 14:59
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] New thrd: dates

Love - and am deeply grateful for, Stuart, the simplicity in that answer.
And the best part were the words "I always use" - which shows this is field tested.

As a side question, I assume you use simply now() when time stamping an access date field on the FE or BE regardless of the location, but what happens when performing a loop and you want to insert all records with no possibility of time stamp variation, such that you hold a date in A variable like

dtStamp= Now ()

Do

    Blah blah inserts record with dtStamp

Loop

Do you use any conversion functions or rely on dtStamp to be a number?
 



From jamesbutton at blueyonder.co.uk  Fri Aug 22 08:13:36 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 22 Aug 2014 14:13:36 +0100
Subject: [AccessD] New thrd: dates
In-Reply-To: <CAJLzs_3x6yP7HkN-sVB+H6sNaTjT-En0JY91FuZRahh34mUUiw@mail.gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD4D1TynKEtHnZ6shrin+6cBAAAAAA==@blueyonder.co.uk>	<043d01cfbd78$8b1d1d60$a1575820$@gmail.com>	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>
	<CAJLzs_3x6yP7HkN-sVB+H6sNaTjT-En0JY91FuZRahh34mUUiw@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAMlgzNQ1+VlMrxvr49abL/QBAAAAAA==@blueyonder.co.uk>

Bill, 

If you want a FE timestamp that could possibly be OK, and a BE timestamp would
probably be done by a stored proc initiated when the entry was added/changed -
with deletion being recorded as a change for audit path, and maybe recovery.

However there is local 'Summer' time to consider - as in you probably want to
avoid an entry indicating  a record was deleted sometime in the hour BEFORE it
was created. 
And there is even more fun when a government decides to change the usual
Summertime period.

To my mind it is best to use the organisations 'home location Standard time' as
in if the organisation is 'based' in NewYork all timestamps are using the
standard time there.
 
It will still be appropriate for many sets of data to include a local timestamp.

Having both allows the results of searches to be shown in timesequence for both
local (legal) purposes, and worldwide for corporate purposes.

JimB

And Bill, please keep asking the questions that are awkward to answer certainly
gets the forum thinking and even some edukatun

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Friday, August 22, 2014 1:59 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

Love - and am deeply grateful for, Stuart, the simplicity in that answer.
And the best part were the words "I always use" - which shows this is
field tested.

As a side question, I assume you use simply now() when time stamping an
access date field on the FE or BE regardless of the location, but what
happens when performing a loop and you want to insert all records with no
possibility of time stamp variation, such that you hold a date in
A variable like

dtStamp= Now ()

Do

    Blah blah inserts record with dtStamp

Loop

Do you use any conversion functions or rely on dtStamp to be a number?
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From Lambert.Heenan at aig.com  Fri Aug 22 08:53:43 2014
From: Lambert.Heenan at aig.com (Heenan, Lambert)
Date: Fri, 22 Aug 2014 13:53:43 +0000
Subject: [AccessD] New thrd: dates
In-Reply-To: <53F68379.4036.F7430003@stuart.lexacorp.com.pg>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>,
	<04ba01cfbd94$81aad620$85008260$@gmail.com>
	<53F68379.4036.F7430003@stuart.lexacorp.com.pg>
Message-ID: <D2D5A45EB26EC34F8199762DC40FFAA8048222@PWGSMSLIVMBS04.mail.aig.net>

Actually DateValue() and CDate() are different. Cdate will convert anything that looks like a date (such as a string) to a Date type value.  DateValue will also convert strings to dates, but its real purpose is to return *JUST* the date. So if the data you pass to it includes a time stamp, you get back just the date, as in...

? datevalue("8/22/2014 9:50:30 AM")
8/22/2014

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Thursday, August 21, 2014 7:41 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

No reason other than habit.  They both do exactly the same thing as far as I can tell.

On 21 Aug 2014 at 19:06, Bill Benson wrote:

> Love - and am deeply grateful for, Stuart, the simplicity in your 
> answer. Loved even more "I always use" w/o problems, that means field 
> tested. Any reason you use DateValue rather than CDate?
> 
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart 
> McLachlan Sent: Thursday, August 21, 2014 5:50 PM To: Access 
> Developers discussion and problem solving Subject: Re: [AccessD] New
> thrd: dates
> 
> OK, here goes as asked for (an Access FE/BE):
> 
> Answers in line.
> 
> On 21 Aug 2014 at 15:46, Bill Benson wrote:
> 
> > I am really sorry I asked this one now! My question "what is meant 
> > by a GUI date just needed a yes or no to my illustration, to wit, "
> > Is this a bound textbox reading a date from the back end?"; [or if 
> > not that, something else - and if so, what?].
> > 
> 
> Yes.   It's the formatted date as displayed in a control on a form or
> report.
> 
> > Jim further said the effect would depend on
> > <<1) the format the data is put into by the BE I already posted:
> > <<my backend had Aug 4th 2014 stored as 08/04/2014
> 
> No, your date is NOT stored iin an Access BE as 08.04/02014.  It is
> stored as the number 41855.0   which is the number of days since 30
> Dec 1899.
> 
> > I had written (*emphasis* added):
> > > When *I take that value* to enter it into the database (remember 
> > > backend is US) would I write
> > >
> > > Sql = "Insert into myTable (name, address, effective_dt) values 
> > > ('" & txtname & "','" & txtaddress & "', #" & txteffectivedate & 
> > > "#)"
> > 
> > > Or
> > > Sql = "Insert into myTable (name, address, effective_dt) values 
> > > ('" & txtname & "','" & txtaddress & "', #" &
> > > cdate(txteffectivedate) & "#)"
> 
> It doesn't matter whether the BE is US or UK, the date is stored as 
> the same number.
> 
> The problem is that the SQL engine in the Access FE requires a date 
> surrounded by "#"s to be in a specific format, which may not be the 
> format in which txtEffectiveDate is being displayed. (In a European 
> FE, the txtEffectiveDate could be 08/04/2014, 04/08/2014,"04 Aug 
> 2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
> formats.)       
> 
> There are two common solutions:
> 
>  Sql = "Insert into myTable (name, address, effective_dt) values ('" &  
> txtname & "','" & txtaddress & _ "', #" & 
> format(txteffectivedate,"mm/dd/yyyy") & "#)"
> 
> or
> 
>  Sql = "Insert into myTable (name, address, effective_dt) values ('" &  
> txtname & "','" & txtaddress & _ "',Datevalue('" & txteffectivedate & 
> "'))"
> 
> FWIW, I always use the second version and have never had a problem 
> with it.
> 
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Fri Aug 22 15:29:17 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 22 Aug 2014 16:29:17 -0400
Subject: [AccessD] New thrd: dates
In-Reply-To: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <071b01cfbe47$bfe90a70$3fbb1f50$@gmail.com>

Thanks Gustav,

I used to work for a business who wanted me to assign a date stamp to a
variable and stamp all records with that date. That was on an Access
backend. I think in SS and Oracle, this is done (as Jim suggested) with
back-end processes ("triggers") that occur when a BATCH - not a record - is
*completed*. There might be an appreciable difference. 

I hope that id batch processing stamps records with a date time after the
last transaction updates, that none of the new information was viewable
until the transaction completes. That puts the onus on the creator of the
transaction to make those transactions fast, because data is technically out
of date all the while a transaction is completing.

I cannot believe there would be any utility to a process which puts a
timestamp of A on a record that is still viewable at some time past A, still
in its non-updated condition, only to reflect the most up to date
information slightly later.

Essentially, doing things the way that senior developer told me to, that was
clearly a risk that I ran.

I'll bet huge sections of courses covering transactions, EDI, whatever, have
been written on this stuff?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Friday, August 22, 2014 9:09 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

Hi Bill

You would rely on dtStamp being a date/time value. The field would be of
data type Date.

The records would be stamped identically with the value of dtStamp.
If you want the real time as close as possible, for example in a loop of
long duration in VBA, you would call Now within the loop for each insertion.

/gustav



From stuart at lexacorp.com.pg  Fri Aug 22 16:02:06 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 23 Aug 2014 07:02:06 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <CAJLzs_3x6yP7HkN-sVB+H6sNaTjT-En0JY91FuZRahh34mUUiw@mail.gmail.com>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<53F66990.29345.F6DDC9A6@stuart.lexacorp.com.pg>,
	<CAJLzs_3x6yP7HkN-sVB+H6sNaTjT-En0JY91FuZRahh34mUUiw@mail.gmail.com>
Message-ID: <53F7AFCE.11894.FBD82C68@stuart.lexacorp.com.pg>

You can just use dtStamp.   .Same as you can safely use Now() directly for a simgle date 
stamp.

The problems only occur when using external representations of dates derived from  GUI 
controls - it is the interpretation of string representations of dates that cause them.

-- 
Stuart

On 22 Aug 2014 at 8:58, Bill Benson wrote:

> Love - and am deeply grateful for, Stuart, the simplicity in that
> answer. And the best part were the words "I always use" - which shows
> this is field tested.
> 
> As a side question, I assume you use simply now() when time stamping
> an access date field on the FE or BE regardless of the location, but
> what happens when performing a loop and you want to insert all records
> with no possibility of time stamp variation, such that you hold a date
> in A variable like
> 
> dtStamp= Now ()
> 
> Do
> 
>     Blah blah inserts record with dtStamp
> 
> Loop
> 
> Do you use any conversion functions or rely on dtStamp to be a number?
> -- AccessD mailing list AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd Website:
> http://www.databaseadvisors.com
> 



From stuart at lexacorp.com.pg  Fri Aug 22 16:05:39 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 23 Aug 2014 07:05:39 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAMlgzNQ1+VlMrxvr49abL/QBAAAAAA==@blueyonder.co.uk>
Message-ID: <53F7B0A3.23334.FBDB6E86@stuart.lexacorp.com.pg>

The best solution in a geographically diverse situation is to store all dates/imes as UTC  (or 
as "Unix Time")

It's simple to convert between UTC and local time when required with a couple of API calls.
Unix/Local is also fairly simple.

-- 
Stuart


On 22 Aug 2014 at 14:13, James Button wrote:

> 
> To my mind it is best to use the organisations 'home location Standard
> time' as in if the organisation is 'based' in NewYork all timestamps
> are using the standard time there.
> 
> It will still be appropriate for many sets of data to include a local
> timestamp.
> 
> Having both allows the results of searches to be shown in timesequence
> for both local (legal) purposes, and worldwide for corporate purposes.
> 
> JimB
> 
> And Bill, please keep asking the questions that are awkward to answer
> certainly gets the forum thinking and even some edukatun
> 


From stuart at lexacorp.com.pg  Fri Aug 22 16:09:36 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 23 Aug 2014 07:09:36 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <D2D5A45EB26EC34F8199762DC40FFAA8048222@PWGSMSLIVMBS04.mail.aig.net>
References: <CAJLzs_3WC14ovjOms4svmX-MuKj4fqSdo34a97Uv-cAWe7aVeA@mail.gmail.com>,
	<53F68379.4036.F7430003@stuart.lexacorp.com.pg>,
	<D2D5A45EB26EC34F8199762DC40FFAA8048222@PWGSMSLIVMBS04.mail.aig.net>
Message-ID: <53F7B190.1116.FBDF09EA@stuart.lexacorp.com.pg>

Good point.  You are correct of course, Datevalue()  =  INT(CDate())

I wasn't thinking about the time part when I said that.  I was just thinking about storing dates 
and comparing dates, not timestamps.  



-- 
Stuart

On 22 Aug 2014 at 13:53, Heenan, Lambert wrote:

> Actually DateValue() and CDate() are different. Cdate will convert
> anything that looks like a date (such as a string) to a Date type
> value.  DateValue will also convert strings to dates, but its real
> purpose is to return *JUST* the date. So if the data you pass to it
> includes a time stamp, you get back just the date, as in...
> 
> ? datevalue("8/22/2014 9:50:30 AM")
> 8/22/2014
> 
> Lambert
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Thursday, August 21, 2014 7:41 PM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD] New
> thrd: dates
> 
> No reason other than habit.  They both do exactly the same thing as
> far as I can tell.
> 
> On 21 Aug 2014 at 19:06, Bill Benson wrote:
> 
> > Love - and am deeply grateful for, Stuart, the simplicity in your
> > answer. Loved even more "I always use" w/o problems, that means
> > field tested. Any reason you use DateValue rather than CDate?
> > 
> > 
> > 
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan Sent: Thursday, August 21, 2014 5:50 PM To: Access
> > Developers discussion and problem solving Subject: Re: [AccessD] New
> > thrd: dates
> > 
> > OK, here goes as asked for (an Access FE/BE):
> > 
> > Answers in line.
> > 
> > On 21 Aug 2014 at 15:46, Bill Benson wrote:
> > 
> > > I am really sorry I asked this one now! My question "what is meant
> > > by a GUI date just needed a yes or no to my illustration, to wit,
> > > " Is this a bound textbox reading a date from the back end?"; [or
> > > if not that, something else - and if so, what?].
> > > 
> > 
> > Yes.   It's the formatted date as displayed in a control on a form
> > or report.
> > 
> > > Jim further said the effect would depend on
> > > <<1) the format the data is put into by the BE I already posted:
> > > <<my backend had Aug 4th 2014 stored as 08/04/2014
> > 
> > No, your date is NOT stored iin an Access BE as 08.04/02014.  It is
> > stored as the number 41855.0   which is the number of days since 30
> > Dec 1899.
> > 
> > > I had written (*emphasis* added):
> > > > When *I take that value* to enter it into the database (remember
> > > > backend is US) would I write
> > > >
> > > > Sql = "Insert into myTable (name, address, effective_dt) values
> > > > ('" & txtname & "','" & txtaddress & "', #" & txteffectivedate &
> > > > "#)"
> > > 
> > > > Or
> > > > Sql = "Insert into myTable (name, address, effective_dt) values
> > > > ('" & txtname & "','" & txtaddress & "', #" &
> > > > cdate(txteffectivedate) & "#)"
> > 
> > It doesn't matter whether the BE is US or UK, the date is stored as
> > the same number.
> > 
> > The problem is that the SQL engine in the Access FE requires a date
> > surrounded by "#"s to be in a specific format, which may not be the
> > format in which txtEffectiveDate is being displayed. (In a European
> > FE, the txtEffectiveDate could be 08/04/2014, 04/08/2014,"04 Aug
> > 2014","Aug 4 2014" , "Auot 4 2014", or many other language specific
> > formats.)       
> > 
> > There are two common solutions:
> > 
> >  Sql = "Insert into myTable (name, address, effective_dt) values ('"
> >  &  
> > txtname & "','" & txtaddress & _ "', #" & 
> > format(txteffectivedate,"mm/dd/yyyy") & "#)"
> > 
> > or
> > 
> >  Sql = "Insert into myTable (name, address, effective_dt) values ('"
> >  &  
> > txtname & "','" & txtaddress & _ "',Datevalue('" & txteffectivedate
> > & "'))"
> > 
> > FWIW, I always use the second version and have never had a problem
> > with it.
> > 
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From gustav at cactus.dk  Sat Aug 23 04:39:13 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Sat, 23 Aug 2014 09:39:13 +0000
Subject: [AccessD] New thrd: dates
In-Reply-To: <071b01cfbe47$bfe90a70$3fbb1f50$@gmail.com>
References: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>,
	<071b01cfbe47$bfe90a70$3fbb1f50$@gmail.com>
Message-ID: <1408786752676.75550@cactus.dk>

Hi Bill

You can say that with an Access backend, a timestamp has to be produced by the frontend, while with a server backend like SQL Server, a timestamp is normally produced by the backend engine. However, the nature of those timestamps may be very different. For SQL Server, a timestamp is not readable as a time, it's for internal use only.

/gustav
________________________________________
Fra: accessd-bounces at databaseadvisors.com <accessd-bounces at databaseadvisors.com> p? vegne af Bill Benson <bensonforums at gmail.com>
Sendt: 22. august 2014 22:29
Til: 'Access Developers discussion and problem solving'
Emne: Re: [AccessD] New thrd: dates

Thanks Gustav,

I used to work for a business who wanted me to assign a date stamp to a
variable and stamp all records with that date. That was on an Access
backend. I think in SS and Oracle, this is done (as Jim suggested) with
back-end processes ("triggers") that occur when a BATCH - not a record - is
*completed*. There might be an appreciable difference.

I hope that id batch processing stamps records with a date time after the
last transaction updates, that none of the new information was viewable
until the transaction completes. That puts the onus on the creator of the
transaction to make those transactions fast, because data is technically out
of date all the while a transaction is completing.

I cannot believe there would be any utility to a process which puts a
timestamp of A on a record that is still viewable at some time past A, still
in its non-updated condition, only to reflect the most up to date
information slightly later.

Essentially, doing things the way that senior developer told me to, that was
clearly a risk that I ran.

I'll bet huge sections of courses covering transactions, EDI, whatever, have
been written on this stuff?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Friday, August 22, 2014 9:09 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] New thrd: dates

Hi Bill

You would rely on dtStamp being a date/time value. The field would be of
data type Date.

The records would be stamped identically with the value of dtStamp.
If you want the real time as close as possible, for example in a loop of
long duration in VBA, you would call Now within the loop for each insertion.

/gustav


From stuart at lexacorp.com.pg  Sat Aug 23 05:23:39 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 23 Aug 2014 20:23:39 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <1408786752676.75550@cactus.dk>
References: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>,
	<071b01cfbe47$bfe90a70$3fbb1f50$@gmail.com>,
	<1408786752676.75550@cactus.dk>
Message-ID: <53F86BAB.8218.FEB6069F@stuart.lexacorp.com.pg>

That's why they changed the name of the SQL Server TIMESTAMP to  ROWVERSION (in 
2005?) - a much more accurate description of its purpose and structure.



On 23 Aug 2014 at 9:39, Gustav Brock wrote:

> Hi Bill
> 
> You can say that with an Access backend, a timestamp has to be
> produced by the frontend, while with a server backend like SQL Server,
> a timestamp is normally produced by the backend engine. However, the
> nature of those timestamps may be very different. For SQL Server, a
> timestamp is not readable as a time, it's for internal use only.
> 
> /gustav


From stuart at lexacorp.com.pg  Sat Aug 23 05:31:23 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 23 Aug 2014 20:31:23 +1000
Subject: [AccessD] New thrd: dates
In-Reply-To: <1408786752676.75550@cactus.dk>
References: <3f75c7ed7889404c835e51f76a0eb9ee@AMSPR06MB357.eurprd06.prod.outlook.com>,
	<071b01cfbe47$bfe90a70$3fbb1f50$@gmail.com>,
	<1408786752676.75550@cactus.dk>
Message-ID: <53F86D7B.5941.FEBD1ADA@stuart.lexacorp.com.pg>

There are at least two external uses for the SQL Server TIMESTAMP/ROWVERSION.that I 
can think of:

1. Requery it before saving updates to see whether the record has been changed by another 
user.

2.  Since it is a sequential value, you can query how many/what other records have been 
updated since any specific record was last updated.

-- 
Stuart  


On 23 Aug 2014 at 9:39, Gustav Brock wrote:

> Hi Bill
> 
> You can say that with an Access backend, a timestamp has to be
> produced by the frontend, while with a server backend like SQL Server,
> a timestamp is normally produced by the backend engine. However, the
> nature of those timestamps may be very different. For SQL Server, a
> timestamp is not readable as a time, it's for internal use only.
> 


From bensonforums at gmail.com  Sat Aug 23 10:22:07 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Sat, 23 Aug 2014 11:22:07 -0400
Subject: [AccessD] Pasting into Excel
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAALO/MfT9vuVEhL3yUGedPRUBAAAAAA==@blueyonder.co.uk>
References: <CAMhYZWbrzFoGSNkRgNXg4P-GzRHj8-kAaR4Q+uV1oOkjmgbT2w@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAALO/MfT9vuVEhL3yUGedPRUBAAAAAA==@blueyonder.co.uk>
Message-ID: <CAJLzs_13bhLa-McrpdXYeS+Vq4boiYXwyqrk4y7bvHyxzn8FZw@mail.gmail.com>

I think the wrap has always occurred in every version, and is not due to
encountering a new line character- that is why removing line wrap
straightens it out. Probably it is something kind of natural reaction excel
has to table-type pastable data. In the query panel there are cells but
when copying only a limited amount (and some is transcribed) of the
formatting meta data is brought over. My thinking was (and one time) this
was some kind of delimiter, acting like the import of a csv, you know,
interpreting query grid walls like commas... but I don't think that's true
any more...

May be a good reason to use automation and via to save on repeated manual
effort.
On Aug 21, 2014 2:11 PM, "James Button" <jamesbutton at blueyonder.co.uk>
wrote:

> Consider that Paste includes some (not all) of the formatting - either
> actual as
> in where Excel recognises dates (well, thinks? It has).
> There is paste Special values that will not (well probably not) change the
> formatting of cells.
>
> Re dates - you will need to consider the data being posted (as in what is
> its
> format)
> The country code of the OS, the country code of Excel, the defaults set,
> and
> what format is specified for the cells getting the data.
>
> AFAIK Excel  sets Wrap if it finds a newline in the text string
>
> Now you mention Excel 2007, but do not explicitly state what version you
> are
> using, or what OS, which could also have some effect on the clipboard
> handling.
>
> Re your question:
> No! It's MS software!
>
> JimB
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee
> Sent: Thursday, August 21, 2014 6:18 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Pasting into Excel
>
> I know this question should really go to Excel-L rather than Access-D, but
> you're all a smart bunch so I figured I'd ask here first. ;)
>
>
> A pet peeve of mine is pasting data from and Access Query or SQL Server
> Management Studio into Excel and the data is wrapped and dates always show
> up weird.
>
> I don't remember this occurring before Office 2007 (but I can't remember
> past last weekend much less 7 years ago).
>
> So every time I paste a big grid of data, I have to toggle "wrap text"
> three times.
>
> If I choose "Short Date" from the formatting drop down in the number
> toolbar (in the ribbon) the dates will change to short dates.
>
> If I past the same (or different) data from the clip board it reverts back,
> losing the short data and non wrapped text formatting.
>
> Am I silly to think it didn't work this way in earlier versions?
>
> Thanks,
> David
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From cjlabs at att.net  Sat Aug 23 13:44:23 2014
From: cjlabs at att.net (Carolyn Johnson)
Date: Sat, 23 Aug 2014 13:44:23 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>,
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>,
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>
Message-ID: <DC075451DA044F8D94DA6B22A7054731@Dell>

I finally had time to update one of my Win8 computers to Win8.1 and was able to reproduce the error.  It's definitely Win 8.1 -- I reverting back to Win 8, and did the Win 8 updates, and it worked with bothof those configurations.  Put Win8.1 back on and it doesn't work.

The information from one of my users that it was the attachments was incorrect.

After commenting a bunch of stuff out that wasn't related to creating the email itself, I found:


My code had
    .Body = Form_fdlgSendEmail.txtBody

referring to the form which calls the sub 


For some reason Win 8.1 does not like this.   I've fixed it with

    strBody = Form_fdlgSendEmail.txtBody
    .body = strBody



Carolyn Johnson

From garykjos at gmail.com  Sun Aug 24 08:23:34 2014
From: garykjos at gmail.com (Gary Kjos)
Date: Sun, 24 Aug 2014 08:23:34 -0500
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
In-Reply-To: <DC075451DA044F8D94DA6B22A7054731@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>
	<DC075451DA044F8D94DA6B22A7054731@Dell>
Message-ID: <CAJ2R_p+FcztxcZrBkL1MB9YzD=D06UT2JbFXb-1AadisDXoLJg@mail.gmail.com>

Thanks for the update!

On Sat, Aug 23, 2014 at 1:44 PM, Carolyn Johnson <cjlabs at att.net> wrote:
> I finally had time to update one of my Win8 computers to Win8.1 and was able to reproduce the error.  It's definitely Win 8.1 -- I reverting back to Win 8, and did the Win 8 updates, and it worked with bothof those configurations.  Put Win8.1 back on and it doesn't work.
>
> The information from one of my users that it was the attachments was incorrect.
>
> After commenting a bunch of stuff out that wasn't related to creating the email itself, I found:
>
>
> My code had
>     .Body = Form_fdlgSendEmail.txtBody
>
> referring to the form which calls the sub
>
>
> For some reason Win 8.1 does not like this.   I've fixed it with
>
>     strBody = Form_fdlgSendEmail.txtBody
>     .body = strBody
>
>
>
> Carolyn Johnson
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com



-- 
Gary Kjos
garykjos at gmail.com


From marksimms at verizon.net  Sun Aug 24 17:47:42 2014
From: marksimms at verizon.net (Mark Simms)
Date: Sun, 24 Aug 2014 18:47:42 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
In-Reply-To: <DC075451DA044F8D94DA6B22A7054731@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>,
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>,
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>
	<DC075451DA044F8D94DA6B22A7054731@Dell>
Message-ID: <001f01cfbfed$6a7c2930$3f747b90$@net>

This totally confirms my observations of how shaky the VBA interpreter can
be.......
You should see what happens in a Citrix environment.....total flake city.
>
> My code had
>     .Body = Form_fdlgSendEmail.txtBody
>
> referring to the form which calls the sub
>
>
> For some reason Win 8.1 does not like this.   I've fixed it with
>
>     strBody = Form_fdlgSendEmail.txtBody
>     .body = strBody
>
> Carolyn Johnson
> --



From bensonforums at gmail.com  Tue Aug 26 09:27:48 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Tue, 26 Aug 2014 10:27:48 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
In-Reply-To: <DC075451DA044F8D94DA6B22A7054731@Dell>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>
	<DC075451DA044F8D94DA6B22A7054731@Dell>
Message-ID: <CAJLzs_1X0SzUkdk=bxnu_BHeCfR9GusVQKbsunNcwgsN-Au8jw@mail.gmail.com>

Has anyone else verified this within this List?


I don't have that version of windows, I stopped at 7. I wish MS had.

Carolyn's kind of automation task is a ubiquitous (I am tempted to say
vital) one for even casual VBA developers.

1) isn't anyone here who has win 8.1 on their hd (or vm) going to set up a
small test to try to duplicate the problem?

2) can there be any justified reason MS would not be interested in hearing
about this and fixing, if it happens consistently and an Access MVP relayed
it to them?

No takers here? More fun (though less charitable) than the ice bucket
challenge.

If I had windows 8.1 I know I would surely be testing my mailer code...

From jimdettman at verizon.net  Tue Aug 26 11:45:36 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Tue, 26 Aug 2014 12:45:36 -0400
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
In-Reply-To: <CAJLzs_1X0SzUkdk=bxnu_BHeCfR9GusVQKbsunNcwgsN-Au8jw@mail.gmail.com>
References: <36.4E.01452.C016BE35@camino.dc.lsoft.com>
	<CAKvidAtUKVA3vyhnfXxN2kVpJFo580htw7fAF2X_pM=w-s7WYw@mail.gmail.com>
	<09afcf40e2534ae3a5df693c418cae97@BLUPR0501MB884.namprd05.prod.outlook.com>
	<53EC0204.30326.CE396C35@stuart.lexacorp.com.pg>
	<DC075451DA044F8D94DA6B22A7054731@Dell>
	<CAJLzs_1X0SzUkdk=bxnu_BHeCfR9GusVQKbsunNcwgsN-Au8jw@mail.gmail.com>
Message-ID: <29213A12A4F94281B9E37AC639E84569@XPS>

Bill,

  In answer to you questions:

A. From my viewpoint here, no one in the business world is using Windows 8.1
extensively, let alone 8.0.  On tablets yes, but not running business apps
with it on the desktop.

B. Microsoft's total focus is the web and nothing but the web.  Anything
outside of that is an uphill battle.   I brought up a problem with SMB2/3
under Windows Server 2012 and got absolute silence.   No one is taking about
the desktop anymore.

   Also given that while it breaks, but that the work around is simple, I'd
doubt they'd address it with anything more than possibly a MSKB article.   I
think you'll find that unless it leads to something like data loss and the
conditions under which it can occur are wide spread, it would not get fixed.
That's been the on-going pattern for a number of years.
 
   So no, no taker here.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Tuesday, August 26, 2014 10:28 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED

Has anyone else verified this within this List?


I don't have that version of windows, I stopped at 7. I wish MS had.

Carolyn's kind of automation task is a ubiquitous (I am tempted to say
vital) one for even casual VBA developers.

1) isn't anyone here who has win 8.1 on their hd (or vm) going to set up a
small test to try to duplicate the problem?

2) can there be any justified reason MS would not be interested in hearing
about this and fixing, if it happens consistently and an Access MVP relayed
it to them?

No takers here? More fun (though less charitable) than the ice bucket
challenge.

If I had windows 8.1 I know I would surely be testing my mailer code...
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From darren at activebilling.com.au  Tue Aug 26 19:14:34 2014
From: darren at activebilling.com.au (Darren)
Date: Wed, 27 Aug 2014 10:14:34 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
Message-ID: <37D2B78732AC4A15B5F28D231F6E217E@DDNote>

Hi Y'all
Do any of you have experience connecting to GMAIL from Access?
IE - Sending emails via the GMAIL account using Access Screens etc.
I found some 'dead' links on the googles, not much else for VBA.
Many thanks in advance
Darren
 

From newsgrps at dalyn.co.nz  Tue Aug 26 19:25:08 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Wed, 27 Aug 2014 12:25:08 +1200
Subject: [AccessD] Reports Not Reaching Printer
Message-ID: <003a01cfc18d$5b975e70$12c61b50$@dalyn.co.nz>

Hi Listers,

 

I have a company where an Access 2010 FE mdb is run on a number of computers
all linked to the same printer on the network.  All the users have Access
2010 runtime installed and Office 2010 except for 1.  This user has Office
2013 (but Access 2010 runtime).

 

All the other users can view and print any report to the printer except the
2013 user.  She can view the reports on the screen but when they are sent to
the printer from the Print menu Windows notification area (bottom RHS of
Task bar) says it is printing (but only the first page) and nothing arrives
at the printer or is on the print queue.  EXCEPT FOR 1 REPORT!!!!

 

I have looked at the report properties to see if there is a difference but I
can't see any and would not really know where to look for a "Do not print
this report even if asked to" setting.

 

Has anyone come across this before?  Any suggestions for tracking down the
problem?

 

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand

 

 


From stuart at lexacorp.com.pg  Tue Aug 26 19:37:41 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 27 Aug 2014 10:37:41 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <37D2B78732AC4A15B5F28D231F6E217E@DDNote>
References: <>, <37D2B78732AC4A15B5F28D231F6E217E@DDNote>
Message-ID: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>

I would build the email in code from the various text boxes and use  Blat.DLL to send it to 
GMail.

-- 
Stuart

On 27 Aug 2014 at 10:14, Darren wrote:

> Hi Y'all
> Do any of you have experience connecting to GMAIL from Access?
> IE - Sending emails via the GMAIL account using Access Screens etc. I
> found some 'dead' links on the googles, not much else for VBA. Many
> thanks in advance Darren
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From stuart at lexacorp.com.pg  Tue Aug 26 19:37:47 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 27 Aug 2014 10:37:47 +1000
Subject: [AccessD] Reports Not Reaching Printer
In-Reply-To: <003a01cfc18d$5b975e70$12c61b50$@dalyn.co.nz>
References: <003a01cfc18d$5b975e70$12c61b50$@dalyn.co.nz>
Message-ID: <53FD285B.16109.1136F4A6@stuart.lexacorp.com.pg>

What is the Default printer on the 2013 machine?

Is the one that is working configured to use a specfic printer rather than Default?

-- 
Stuart

On 27 Aug 2014 at 12:25, David Emerson wrote:

> Hi Listers,
> 
> 
> 
> I have a company where an Access 2010 FE mdb is run on a number of
> computers all linked to the same printer on the network.  All the
> users have Access 2010 runtime installed and Office 2010 except for 1.
>  This user has Office 2013 (but Access 2010 runtime).
> 
> 
> 
> All the other users can view and print any report to the printer
> except the 2013 user.  She can view the reports on the screen but when
> they are sent to the printer from the Print menu Windows notification
> area (bottom RHS of Task bar) says it is printing (but only the first
> page) and nothing arrives at the printer or is on the print queue. 
> EXCEPT FOR 1 REPORT!!!!
> 
> 
> 
> I have looked at the report properties to see if there is a difference
> but I can't see any and would not really know where to look for a "Do
> not print this report even if asked to" setting.
> 
> 
> 
> Has anyone come across this before?  Any suggestions for tracking down
> the problem?
> 
> 
> 
> Regards
> 
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
> 
> 
> 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From newsgrps at dalyn.co.nz  Tue Aug 26 19:53:50 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Wed, 27 Aug 2014 12:53:50 +1200
Subject: [AccessD] Reports Not Reaching Printer
In-Reply-To: <53FD285B.16109.1136F4A6@stuart.lexacorp.com.pg>
References: <003a01cfc18d$5b975e70$12c61b50$@dalyn.co.nz>
	<53FD285B.16109.1136F4A6@stuart.lexacorp.com.pg>
Message-ID: <004e01cfc191$5defa980$19cefc80$@dalyn.co.nz>

Hi Stuart,

There is only one printer in the company and it is set as the default for
all machines.

Regards

David

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, 27 August 2014 12:38 p.m.
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Reports Not Reaching Printer

What is the Default printer on the 2013 machine?

Is the one that is working configured to use a specfic printer rather than
Default?

--
Stuart

On 27 Aug 2014 at 12:25, David Emerson wrote:

> Hi Listers,
> 
> I have a company where an Access 2010 FE mdb is run on a number of 
> computers all linked to the same printer on the network.  All the 
> users have Access 2010 runtime installed and Office 2010 except for 1.
>  This user has Office 2013 (but Access 2010 runtime).
> 
> All the other users can view and print any report to the printer 
> except the 2013 user.  She can view the reports on the screen but when 
> they are sent to the printer from the Print menu Windows notification 
> area (bottom RHS of Task bar) says it is printing (but only the first
> page) and nothing arrives at the printer or is on the print queue. 
> EXCEPT FOR 1 REPORT!!!!
> 
> I have looked at the report properties to see if there is a difference 
> but I can't see any and would not really know where to look for a "Do 
> not print this report even if asked to" setting.
> 
> Has anyone come across this before?  Any suggestions for tracking down 
> the problem?
> 
> Regards
> 
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand



From darren at activebilling.com.au  Tue Aug 26 20:05:11 2014
From: darren at activebilling.com.au (Darren)
Date: Wed, 27 Aug 2014 11:05:11 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>
References: <>, <37D2B78732AC4A15B5F28D231F6E217E@DDNote>
	<53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>
Message-ID: <D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>

Hey Stuart,
Sounds good. I've heard you speak of Blat before. Now it's relevant to me...
so now I'm now listening :-) - lol
So what's involved? How does BLAT work with GMAIL? 

Also - I'll explain what I'm doing. As I'll have a lot of q's for the list
in the coming months, I expect.
I'm about to embark on a big pro-bono exercise for a Community based charity
here. About to write (have a started actually) a tool to manage their
clients and their associated programs. And will do it in Access - all
accessed by (Terminal Server)Remote Desktop logons.
At the moment they are using GMAIL and Google as their email and calendaring
tools. So rather than force them 'into anything', I thought I'd see if I
could 'interact' with whatever they have already in place. 
They have no money it's largely volunteers and non-techies running the show.
So whatever I give them has to be simple with not a lot of upheaval if
possible.
Make sense? I know a lot of you have been in exactly this position before.
Thanks heaps
Darren

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, 27 August 2014 10:38 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

I would build the email in code from the various text boxes and use
Blat.DLL to send it to 
GMail.

-- 
Stuart

On 27 Aug 2014 at 10:14, Darren wrote:

> Hi Y'all
> Do any of you have experience connecting to GMAIL from Access?
> IE - Sending emails via the GMAIL account using Access Screens etc. I
> found some 'dead' links on the googles, not much else for VBA. Many
> thanks in advance Darren
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Tue Aug 26 20:48:51 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 27 Aug 2014 11:48:51 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
Message-ID: <53FD3903.28658.117805F6@stuart.lexacorp.com.pg>

Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you can't use Blat with it 
directly.  You would need to also set up stunnel which would be a real PITA.

-- 
Stuart

On 27 Aug 2014 at 11:05, Darren wrote:

> Hey Stuart,
> Sounds good. I've heard you speak of Blat before. Now it's relevant to
> me... so now I'm now listening :-) - lol So what's involved? How does
> BLAT work with GMAIL? 
> 
> Also - I'll explain what I'm doing. As I'll have a lot of q's for the
> list in the coming months, I expect. I'm about to embark on a big
> pro-bono exercise for a Community based charity here. About to write
> (have a started actually) a tool to manage their clients and their
> associated programs. And will do it in Access - all accessed by
> (Terminal Server)Remote Desktop logons. At the moment they are using
> GMAIL and Google as their email and calendaring tools. So rather than
> force them 'into anything', I thought I'd see if I could 'interact'
> with whatever they have already in place. They have no money it's
> largely volunteers and non-techies running the show. So whatever I
> give them has to be simple with not a lot of upheaval if possible.
> Make sense? I know a lot of you have been in exactly this position
> before. Thanks heaps Darren
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> I would build the email in code from the various text boxes and use
> Blat.DLL to send it to GMail.
> 
> -- 
> Stuart
> 
> On 27 Aug 2014 at 10:14, Darren wrote:
> 
> > Hi Y'all
> > Do any of you have experience connecting to GMAIL from Access?
> > IE - Sending emails via the GMAIL account using Access Screens etc.
> > I found some 'dead' links on the googles, not much else for VBA.
> > Many thanks in advance Darren
> > 
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From darren at activebilling.com.au  Tue Aug 26 21:26:57 2014
From: darren at activebilling.com.au (Darren)
Date: Wed, 27 Aug 2014 12:26:57 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
Message-ID: <B452DA64B02B4D83950DEC128A7E56D6@DDNote>

Thanks Stuart.
Probably explains the lack of examples on the googles.

Anyone have thoughts on getting them to use something like outlook or even
Blat on their RemoteDesktops instead of Gmail?

As for calendaring there are a gajillion calendaring options for Access that
I can explore.

Concept question:
I figure the advantage to having GMAIL and Google calendars is you only need
a network connection and a browser to get at them.
Is it not the same concept with doing things via a RemDesktop?
Just need a network connection, mstsc.exe and an address (host)?
Thanks

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, 27 August 2014 11:49 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you can't
use Blat with it 
directly.  You would need to also set up stunnel which would be a real PITA.

-- 
Stuart

On 27 Aug 2014 at 11:05, Darren wrote:

> Hey Stuart,
> Sounds good. I've heard you speak of Blat before. Now it's relevant to
> me... so now I'm now listening :-) - lol So what's involved? How does
> BLAT work with GMAIL? 
> 
> Also - I'll explain what I'm doing. As I'll have a lot of q's for the
> list in the coming months, I expect. I'm about to embark on a big
> pro-bono exercise for a Community based charity here. About to write
> (have a started actually) a tool to manage their clients and their
> associated programs. And will do it in Access - all accessed by
> (Terminal Server)Remote Desktop logons. At the moment they are using
> GMAIL and Google as their email and calendaring tools. So rather than
> force them 'into anything', I thought I'd see if I could 'interact'
> with whatever they have already in place. They have no money it's
> largely volunteers and non-techies running the show. So whatever I
> give them has to be simple with not a lot of upheaval if possible.
> Make sense? I know a lot of you have been in exactly this position
> before. Thanks heaps Darren
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> I would build the email in code from the various text boxes and use
> Blat.DLL to send it to GMail.
> 
> -- 
> Stuart
> 
> On 27 Aug 2014 at 10:14, Darren wrote:
> 
> > Hi Y'all
> > Do any of you have experience connecting to GMAIL from Access?
> > IE - Sending emails via the GMAIL account using Access Screens etc.
> > I found some 'dead' links on the googles, not much else for VBA.
> > Many thanks in advance Darren
> > 
> > -- 
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From gustav at cactus.dk  Wed Aug 27 01:16:32 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Wed, 27 Aug 2014 06:16:32 +0000
Subject: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED
Message-ID: <aa7870a78a52495fb1e6785e2315d59e@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Jim

I think that sums it quite well. 

Azure is evolving at an amazing speed, and resources allocated must be massive. If in doubt, just browse the recent newsletter:

http://bit.ly/1vlb0t2

It also contains a note about Docker.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Jim Dettman
Sendt: 26. august 2014 18:46
Til: 'Access Developers discussion and problem solving'
Emne: Re: [AccessD] Error creating emails in Outlook in Win8 -- SOLVED

Bill,

  In answer to you questions:

A. From my viewpoint here, no one in the business world is using Windows 8.1 extensively, let alone 8.0.  On tablets yes, but not running business apps with it on the desktop.

B. Microsoft's total focus is the web and nothing but the web.  Anything
outside of that is an uphill battle.   I brought up a problem with SMB2/3
under Windows Server 2012 and got absolute silence.   No one is taking about
the desktop anymore.

   Also given that while it breaks, but that the work around is simple, I'd
doubt they'd address it with anything more than possibly a MSKB article.   I
think you'll find that unless it leads to something like data loss and the conditions under which it can occur are wide spread, it would not get fixed.
That's been the on-going pattern for a number of years.
 
   So no, no taker here.

Jim. 


From gustav at cactus.dk  Wed Aug 27 01:33:39 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Wed, 27 Aug 2014 06:33:39 +0000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <B452DA64B02B4D83950DEC128A7E56D6@DDNote>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
	<B452DA64B02B4D83950DEC128A7E56D6@DDNote>
Message-ID: <717e64f02e484e82a2bbfa79df16698c@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Darren

Stuart is right. Gmail only accepts secure mail on port 567.

Many years ago we used a DLL similar to Blat (not an ActiveX) with great success. It actually never failed. 

It has, of course, evolved and now has lots of features including handling of Gmail, Yahoo and probably outlook.com as well:

http://www.marshallsoft.com/see4vb.htm

It is buyware but that includes excellent support (at that time), and a free evaluation version is for download -as I recall it, it just appended a promotion line to sent e-mails.

But do you really need to send directly via Gmail? Most ISPs offer a free SMTP service (often called a smart-host) which your client could use with standard SMTP on port 25.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Darren
Sendt: 27. august 2014 04:27
Til: 'Access Developers discussion and problem solving'
Emne: Re: [AccessD] A2003: Connecting with GMAIL

Thanks Stuart.
Probably explains the lack of examples on the googles.

Anyone have thoughts on getting them to use something like outlook or even Blat on their RemoteDesktops instead of Gmail?

As for calendaring there are a gajillion calendaring options for Access that I can explore.

Concept question:
I figure the advantage to having GMAIL and Google calendars is you only need a network connection and a browser to get at them.
Is it not the same concept with doing things via a RemDesktop?
Just need a network connection, mstsc.exe and an address (host)?
Thanks

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, 27 August 2014 11:49 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you can't use Blat with it directly.  You would need to also set up stunnel which would be a real PITA.

--
Stuart

On 27 Aug 2014 at 11:05, Darren wrote:

> Hey Stuart,
> Sounds good. I've heard you speak of Blat before. Now it's relevant to 
> me... so now I'm now listening :-) - lol So what's involved? How does 
> BLAT work with GMAIL?
> 
> Also - I'll explain what I'm doing. As I'll have a lot of q's for the 
> list in the coming months, I expect. I'm about to embark on a big 
> pro-bono exercise for a Community based charity here. About to write 
> (have a started actually) a tool to manage their clients and their 
> associated programs. And will do it in Access - all accessed by 
> (Terminal Server)Remote Desktop logons. At the moment they are using 
> GMAIL and Google as their email and calendaring tools. So rather than 
> force them 'into anything', I thought I'd see if I could 'interact'
> with whatever they have already in place. They have no money it's 
> largely volunteers and non-techies running the show. So whatever I 
> give them has to be simple with not a lot of upheaval if possible.
> Make sense? I know a lot of you have been in exactly this position 
> before. Thanks heaps Darren
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart 
> McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access 
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> I would build the email in code from the various text boxes and use 
> Blat.DLL to send it to GMail.
> 
> --
> Stuart
> 
> On 27 Aug 2014 at 10:14, Darren wrote:
> 
> > Hi Y'all
> > Do any of you have experience connecting to GMAIL from Access?
> > IE - Sending emails via the GMAIL account using Access Screens etc.
> > I found some 'dead' links on the googles, not much else for VBA.
> > Many thanks in advance Darren
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Wed Aug 27 02:05:04 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Wed, 27 Aug 2014 17:05:04 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <717e64f02e484e82a2bbfa79df16698c@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<B452DA64B02B4D83950DEC128A7E56D6@DDNote>,
	<717e64f02e484e82a2bbfa79df16698c@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <53FD8320.21937.1299844F@stuart.lexacorp.com.pg>

Another possibility is Sockettools:

http://www.catalyst.com/products/sockettools/

It's not cheap, but has very good reputation in the PowerBASIC community. 

"The SocketTools Library Edition has integrated support for secure, encrypted connections 
using the industry standard Secure Sockets Layer (SSL), Transport Layer Security (TLS) and 
Secure Shell (SSH) protocols. The Library Edition provides an interface for all of the major 
Internet protocols such as HTTP, FTPS, SFTP, SMTPS, POP3S, IMAPS and more."

You can download a 30 day free evaluation.

-- 
Stuart


On 27 Aug 2014 at 6:33, Gustav Brock wrote:

> Hi Darren
> 
> Stuart is right. Gmail only accepts secure mail on port 567.
> 
> Many years ago we used a DLL similar to Blat (not an ActiveX) with
> great success. It actually never failed. 
> 
> It has, of course, evolved and now has lots of features including
> handling of Gmail, Yahoo and probably outlook.com as well:
> 
> http://www.marshallsoft.com/see4vb.htm
> 
> It is buyware but that includes excellent support (at that time), and
> a free evaluation version is for download -as I recall it, it just
> appended a promotion line to sent e-mails.
> 
> But do you really need to send directly via Gmail? Most ISPs offer a
> free SMTP service (often called a smart-host) which your client could
> use with standard SMTP on port 25.
> 
> /gustav
> 
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Darren
> Sendt: 27. august 2014 04:27 Til: 'Access Developers discussion and
> problem solving' Emne: Re: [AccessD] A2003: Connecting with GMAIL
> 
> Thanks Stuart.
> Probably explains the lack of examples on the googles.
> 
> Anyone have thoughts on getting them to use something like outlook or
> even Blat on their RemoteDesktops instead of Gmail?
> 
> As for calendaring there are a gajillion calendaring options for
> Access that I can explore.
> 
> Concept question:
> I figure the advantage to having GMAIL and Google calendars is you
> only need a network connection and a browser to get at them. Is it not
> the same concept with doing things via a RemDesktop? Just need a
> network connection, mstsc.exe and an address (host)? Thanks
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Wednesday, 27 August 2014 11:49 AM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you
> can't use Blat with it directly.  You would need to also set up
> stunnel which would be a real PITA.
> 
> --
> Stuart
> 
> On 27 Aug 2014 at 11:05, Darren wrote:
> 
> > Hey Stuart,
> > Sounds good. I've heard you speak of Blat before. Now it's relevant
> > to me... so now I'm now listening :-) - lol So what's involved? How
> > does BLAT work with GMAIL?
> > 
> > Also - I'll explain what I'm doing. As I'll have a lot of q's for
> > the list in the coming months, I expect. I'm about to embark on a
> > big pro-bono exercise for a Community based charity here. About to
> > write (have a started actually) a tool to manage their clients and
> > their associated programs. And will do it in Access - all accessed
> > by (Terminal Server)Remote Desktop logons. At the moment they are
> > using GMAIL and Google as their email and calendaring tools. So
> > rather than force them 'into anything', I thought I'd see if I could
> > 'interact' with whatever they have already in place. They have no
> > money it's largely volunteers and non-techies running the show. So
> > whatever I give them has to be simple with not a lot of upheaval if
> > possible. Make sense? I know a lot of you have been in exactly this
> > position before. Thanks heaps Darren
> > 
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access
> > Developers discussion and problem solving Subject: Re: [AccessD]
> > A2003: Connecting with GMAIL
> > 
> > I would build the email in code from the various text boxes and use
> > Blat.DLL to send it to GMail.
> > 
> > --
> > Stuart
> > 
> > On 27 Aug 2014 at 10:14, Darren wrote:
> > 
> > > Hi Y'all
> > > Do any of you have experience connecting to GMAIL from Access? IE
> > > - Sending emails via the GMAIL account using Access Screens etc. I
> > > found some 'dead' links on the googles, not much else for VBA.
> > > Many thanks in advance Darren
> > > 
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > > 
> > 
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 




From dw-murphy at cox.net  Wed Aug 27 11:23:23 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Wed, 27 Aug 2014 09:23:23 -0700
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <jeUF1o00C0xgD8Z01eUHPN>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
	<jeUF1o00C0xgD8Z01eUHPN>
Message-ID: <004201cfc213$38f289e0$aad79da0$@cox.net>

You can send email from Access through the GMAIL SMTP server using CDO. I
assume CDO is still in Windows. Many years ago I had a system set up for
user group emails that used this approach. There is a sample and
presentation file on this subject on our Access User Group of San Diego web
site at http://www.augsd.org/Portals/0/Articles/cdomail_v2.zip. You do have
to use the secure port with the Google server. For organizations the Google
services are great since folks can have common calendars, task lists, etc.

Doug

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren
Sent: Tuesday, August 26, 2014 7:27 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] A2003: Connecting with GMAIL

Thanks Stuart.
Probably explains the lack of examples on the googles.

Anyone have thoughts on getting them to use something like outlook or even
Blat on their RemoteDesktops instead of Gmail?

As for calendaring there are a gajillion calendaring options for Access that
I can explore.

Concept question:
I figure the advantage to having GMAIL and Google calendars is you only need
a network connection and a browser to get at them.
Is it not the same concept with doing things via a RemDesktop?
Just need a network connection, mstsc.exe and an address (host)?
Thanks

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, 27 August 2014 11:49 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you can't
use Blat with it directly.  You would need to also set up stunnel which
would be a real PITA.

--
Stuart

On 27 Aug 2014 at 11:05, Darren wrote:

> Hey Stuart,
> Sounds good. I've heard you speak of Blat before. Now it's relevant to 
> me... so now I'm now listening :-) - lol So what's involved? How does 
> BLAT work with GMAIL?
> 
> Also - I'll explain what I'm doing. As I'll have a lot of q's for the 
> list in the coming months, I expect. I'm about to embark on a big 
> pro-bono exercise for a Community based charity here. About to write 
> (have a started actually) a tool to manage their clients and their 
> associated programs. And will do it in Access - all accessed by 
> (Terminal Server)Remote Desktop logons. At the moment they are using 
> GMAIL and Google as their email and calendaring tools. So rather than 
> force them 'into anything', I thought I'd see if I could 'interact'
> with whatever they have already in place. They have no money it's 
> largely volunteers and non-techies running the show. So whatever I 
> give them has to be simple with not a lot of upheaval if possible.
> Make sense? I know a lot of you have been in exactly this position 
> before. Thanks heaps Darren
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart 
> McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access 
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> I would build the email in code from the various text boxes and use 
> Blat.DLL to send it to GMail.
> 
> --
> Stuart
> 
> On 27 Aug 2014 at 10:14, Darren wrote:
> 
> > Hi Y'all
> > Do any of you have experience connecting to GMAIL from Access?
> > IE - Sending emails via the GMAIL account using Access Screens etc.
> > I found some 'dead' links on the googles, not much else for VBA.
> > Many thanks in advance Darren
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Wed Aug 27 16:02:21 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 28 Aug 2014 07:02:21 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <004201cfc213$38f289e0$aad79da0$@cox.net>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<jeUF1o00C0xgD8Z01eUHPN>, <004201cfc213$38f289e0$aad79da0$@cox.net>
Message-ID: <53FE475D.17577.159814BB@stuart.lexacorp.com.pg>

Good call!.

I haven't worked with CDO, but this looks like a good basic tutorial including the UseSSL flag:

http://www.activecallcenter.com/manual/591.htm


On 27 Aug 2014 at 9:23, Doug Murphy wrote:

> You can send email from Access through the GMAIL SMTP server using
> CDO. I assume CDO is still in Windows. Many years ago I had a system
> set up for user group emails that used this approach. There is a
> sample and presentation file on this subject on our Access User Group
> of San Diego web site at
> http://www.augsd.org/Portals/0/Articles/cdomail_v2.zip. You do have to
> use the secure port with the Google server. For organizations the
> Google services are great since folks can have common calendars, task
> lists, etc.
> 
> Doug
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren
> Sent: Tuesday, August 26, 2014 7:27 PM To: 'Access Developers
> discussion and problem solving' Subject: Re: [AccessD] A2003:
> Connecting with GMAIL
> 
> Thanks Stuart.
> Probably explains the lack of examples on the googles.
> 
> Anyone have thoughts on getting them to use something like outlook or
> even Blat on their RemoteDesktops instead of Gmail?
> 
> As for calendaring there are a gajillion calendaring options for
> Access that I can explore.
> 
> Concept question:
> I figure the advantage to having GMAIL and Google calendars is you
> only need a network connection and a browser to get at them. Is it not
> the same concept with doing things via a RemDesktop? Just need a
> network connection, mstsc.exe and an address (host)? Thanks
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: Wednesday, 27 August 2014 11:49 AM To: Access
> Developers discussion and problem solving Subject: Re: [AccessD]
> A2003: Connecting with GMAIL
> 
> Sorry,  just did a bit more checking.  GMail requires SSL/TLS so you
> can't use Blat with it directly.  You would need to also set up
> stunnel which would be a real PITA.
> 
> --
> Stuart
> 
> On 27 Aug 2014 at 11:05, Darren wrote:
> 
> > Hey Stuart,
> > Sounds good. I've heard you speak of Blat before. Now it's relevant
> > to me... so now I'm now listening :-) - lol So what's involved? How
> > does BLAT work with GMAIL?
> > 
> > Also - I'll explain what I'm doing. As I'll have a lot of q's for
> > the list in the coming months, I expect. I'm about to embark on a
> > big pro-bono exercise for a Community based charity here. About to
> > write (have a started actually) a tool to manage their clients and
> > their associated programs. And will do it in Access - all accessed
> > by (Terminal Server)Remote Desktop logons. At the moment they are
> > using GMAIL and Google as their email and calendaring tools. So
> > rather than force them 'into anything', I thought I'd see if I could
> > 'interact' with whatever they have already in place. They have no
> > money it's largely volunteers and non-techies running the show. So
> > whatever I give them has to be simple with not a lot of upheaval if
> > possible. Make sense? I know a lot of you have been in exactly this
> > position before. Thanks heaps Darren
> > 
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> > McLachlan Sent: Wednesday, 27 August 2014 10:38 AM To: Access
> > Developers discussion and problem solving Subject: Re: [AccessD]
> > A2003: Connecting with GMAIL
> > 
> > I would build the email in code from the various text boxes and use
> > Blat.DLL to send it to GMail.
> > 
> > --
> > Stuart
> > 
> > On 27 Aug 2014 at 10:14, Darren wrote:
> > 
> > > Hi Y'all
> > > Do any of you have experience connecting to GMAIL from Access? IE
> > > - Sending emails via the GMAIL account using Access Screens etc. I
> > > found some 'dead' links on the googles, not much else for VBA.
> > > Many thanks in advance Darren
> > > 
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > > 
> > 
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > 
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From davidmcafee at gmail.com  Thu Aug 28 12:16:19 2014
From: davidmcafee at gmail.com (David McAfee)
Date: Thu, 28 Aug 2014 10:16:19 -0700
Subject: [AccessD] Delete Query with a join
Message-ID: <CAMhYZWbUL-gBmsAPh+6SQ1sSoR_oZ0AyUuxcjL0MchS_1HKuzA@mail.gmail.com>

It's been a while since I've used Access (especially the GUI Query tools).

In MSSQL, I can delete a table as such:

DELETE [rpt_DMHClaim 14]
FROM [rpt_DMHClaim 14]
INNER JOIN [qry 01a rpt_DMHClaim 14 Dupes to be deleted]
ON [rpt_DMHClaim 14].ClaimNumber = [qry 01a rpt_DMHClaim 14 Dupes to be
deleted].ClaimNumber AND [rpt_DMHClaim 14].EOB_ID = [qry 01a rpt_DMHClaim
14 Dupes to be deleted].MaxOfEOB_ID



But Access doesn't like that.I thought this would work in Access:

DELETE DISTINCTROW [rpt_DMHClaim 14].*
FROM [rpt_DMHClaim 14]
INNER JOIN [qry 01a rpt_DMHClaim 14 Dupes to be deleted]
ON [rpt_DMHClaim 14].ClaimNumber = [qry 01a rpt_DMHClaim 14 Dupes to be
deleted].ClaimNumber AND [rpt_DMHClaim 14].EOB_ID = [qry 01a rpt_DMHClaim
14 Dupes to be deleted].MaxOfEOB_ID



But I get a message that Access cannot delete from Specified tables

This works, but to me shouldn't be correct:

DELETE [rpt_DMHClaim 14].ClaimNumber, [rpt_DMHClaim 14].EOB_ID
FROM [rpt_DMHClaim 14]
WHERE ((([rpt_DMHClaim 14].ClaimNumber) In (SELECT [ClaimNumber] FROM [qry
01a rpt_DMHClaim 14 Dupes to be deleted] )) AND (([rpt_DMHClaim 14].EOB_ID)
In (SELECT [MaxOfEOB_ID] FROM [qry 01a rpt_DMHClaim 14 Dupes to be deleted]
)));



Does anyone see what mistake I am making?

TIA

D

From DMcGillivray at ctc.ca.gov  Thu Aug 28 17:27:55 2014
From: DMcGillivray at ctc.ca.gov (McGillivray, Don)
Date: Thu, 28 Aug 2014 22:27:55 +0000
Subject: [AccessD] Alternatives to domain aggregate functions
Message-ID: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>

Hi Listers,

I have a form in an Access application (users have the Access 2010 runtime only, on Win 7;  Split FE/BE, with BE on network share) where I need to display and continuously evaluate the cumulative count and value of items and assign an incrementing serial number to child records as they are entered.  At this point, the form uses domain aggregate functions to determine the count and sum of the transactions, and the max plus 1 for the next serial number.  At modest volumes (<=200 records) performance is acceptable.  Beyond that, performance becomes increasingly degraded, to the point of being almost unusable by the time 400 records have been entered.

Obviously, the domain aggregate approach is not working for this situation, so I'm looking for more efficient approaches to fulfill the aggregating/incrementing requirements.  Can anybody point me in a better direction?

Thanks!

Don McGillivray

---------------------------------------------------------------------------
For those interested in further detail, please read on . . .

The application records customer payment data.  Ultimately, the payment data collected by the system will be imported into an Oracle database.  The payments, each consisting of a header record and one or more GL distribution records, are entered in batches that correspond to daily bank deposits.  The payment header record contains the payment date, check number, and amount, and the GL distribution record contains line item detail including an application number and the GL account to which the revenue is booked.  Data entry begins with the creation of a batch (deposit) header record that includes the date, number of payments, number of applications paid for, and total deposit amount.  (The item count and amount are used as "target" values during data entry to ensure that everything balances in the end.)  Once the batch header record is complete, the payment records are entered one at a time, along with their GL details.  So I have a simple hierarchy of data entities: Deposit Header - Payment Header - Payment Details, and the entry form is designed (main form, sub-form, sub-form) to accommodate this structure.  That's the quick and dirty description of the basic setup.

A further wrinkle is that each payment record (child of the top level) is associated to one or more stamp numbers that are affixed to the check upon receipt, and those numbers must be included in the distribution records (grandchildren to the top level) for each payment.  The stamp numbers are composed of a date string (YYMMDD) followed by an incrementing serial number from 1 to n each day, according to the number of applications being paid for.  So, based on the application count of the batch header, a list of stamp numbers can be generated for each batch, and, assuming the checks are entered in stamp number order, the next available number may be assigned automatically to each payment until all are used up.  The entry form allows the user to select from a combo box any valid stamp number for any payment if necessary, but the typical scenario is to allow the system to assign the numbers in sequence to the distribution records automatically.

To help ensure accurate data entry, the user is required to have entered values that agree with the target values.  For example, on a given payment, before a new payment may be entered, the value of the distribution records must equal the check amount as entered in the payment header.  Similarly, the batch itself may not be posted until the sum of its payment records equals the previously entered batch totals (item count and amount.)  These rules are enforced by the form by comparing the batch and payment header entries to the sums of the line items as data is entered.

The application has been in production since May, and has functioned well as designed.  However, this week an unusually large volume of payments (>600) arrived on a single day, and as the batch entry progressed beyond about 300 records, the form's performance became increasingly degraded, until it was essentially unusable.  The degradation is probably due to the methods I've employed to determine the next available stamp number, compounded by the tabulation of the item count and cumulative total for the batch as data entry progresses.  In both cases, I'm using domain aggregate functions to return the count and sum of payments entered, along with the max plus 1 for the next available stamp number.  As the number of records in the batch grows, these calculations take longer and longer.  The effect was observed during development, leading me to modify the table structure so that new records land in temporary tables before being posted by the user to the permanent ones.  This improved things quite a bit by avoiding the impact of aggregating over a table whose content continues to grow over time, but apparently that move is not enough when the batch volume rises beyond a certain point.

From stuart at lexacorp.com.pg  Thu Aug 28 19:14:34 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 29 Aug 2014 10:14:34 +1000
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
Message-ID: <53FFC5EA.8912.1B6E6A57@stuart.lexacorp.com.pg>

Do you have an appropriate index on the field(s) being aggregated? I suspect not.

On 28 Aug 2014 at 22:27, McGillivray, Don wrote:

> Hi Listers,
> 
> I have a form in an Access application (users have the Access 2010
> runtime only, on Win 7;  Split FE/BE, with BE on network share) where
> I need to display and continuously evaluate the cumulative count and
> value of items and assign an incrementing serial number to child
> records as they are entered.  At this point, the form uses domain
> aggregate functions to determine the count and sum of the
> transactions, and the max plus 1 for the next serial number.  At
> modest volumes (<=200 records) performance is acceptable.  Beyond
> that, performance becomes increasingly degraded, to the point of being
> almost unusable by the time 400 records have been entered.
> 
> Obviously, the domain aggregate approach is not working for this
> situation, so I'm looking for more efficient approaches to fulfill the
> aggregating/incrementing requirements.  Can anybody point me in a
> better direction?
> 
> Thanks!
> 
> Don McGillivray
> 
> ----------------------------------------------------------------------
> ----- For those interested in further detail, please read on . . .
> 
> The application records customer payment data.  Ultimately, the
> payment data collected by the system will be imported into an Oracle
> database.  The payments, each consisting of a header record and one or
> more GL distribution records, are entered in batches that correspond
> to daily bank deposits.  The payment header record contains the
> payment date, check number, and amount, and the GL distribution record
> contains line item detail including an application number and the GL
> account to which the revenue is booked.  Data entry begins with the
> creation of a batch (deposit) header record that includes the date,
> number of payments, number of applications paid for, and total deposit
> amount.  (The item count and amount are used as "target" values during
> data entry to ensure that everything balances in the end.)  Once the
> batch header record is complete, the payment records are entered one
> at a time, along with their GL details.  So I have a simple hierarchy
> of data entities: Deposit !
>  Header - Payment Header - Payment Details, and the entry form is
>  designed (main form, sub-form, sub-form) to accommodate this
>  structure.  That's the quick and dirty description of the basic
>  setup.
> 
> A further wrinkle is that each payment record (child of the top level)
> is associated to one or more stamp numbers that are affixed to the
> check upon receipt, and those numbers must be included in the
> distribution records (grandchildren to the top level) for each
> payment.  The stamp numbers are composed of a date string (YYMMDD)
> followed by an incrementing serial number from 1 to n each day,
> according to the number of applications being paid for.  So, based on
> the application count of the batch header, a list of stamp numbers can
> be generated for each batch, and, assuming the checks are entered in
> stamp number order, the next available number may be assigned
> automatically to each payment until all are used up.  The entry form
> allows the user to select from a combo box any valid stamp number for
> any payment if necessary, but the typical scenario is to allow the
> system to assign the numbers in sequence to the distribution records
> automatically.
> 
> To help ensure accurate data entry, the user is required to have
> entered values that agree with the target values.  For example, on a
> given payment, before a new payment may be entered, the value of the
> distribution records must equal the check amount as entered in the
> payment header.  Similarly, the batch itself may not be posted until
> the sum of its payment records equals the previously entered batch
> totals (item count and amount.)  These rules are enforced by the form
> by comparing the batch and payment header entries to the sums of the
> line items as data is entered.
> 
> The application has been in production since May, and has functioned
> well as designed.  However, this week an unusually large volume of
> payments (>600) arrived on a single day, and as the batch entry
> progressed beyond about 300 records, the form's performance became
> increasingly degraded, until it was essentially unusable.  The
> degradation is probably due to the methods I've employed to determine
> the next available stamp number, compounded by the tabulation of the
> item count and cumulative total for the batch as data entry
> progresses.  In both cases, I'm using domain aggregate functions to
> return the count and sum of payments entered, along with the max plus
> 1 for the next available stamp number.  As the number of records in
> the batch grows, these calculations take longer and longer.  The
> effect was observed during development, leading me to modify the table
> structure so that new records land in temporary tables before being
> posted by the user to the permanent ones.  This im!
>  proved things quite a bit by avoiding the impact of aggregating over
>  a table whose content continues to grow over time, but apparently
>  that move is not enough when the batch volume rises beyond a certain
>  point.
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From jimdettman at verizon.net  Thu Aug 28 19:35:09 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Thu, 28 Aug 2014 20:35:09 -0400
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <53FFC5EA.8912.1B6E6A57@stuart.lexacorp.com.pg>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<53FFC5EA.8912.1B6E6A57@stuart.lexacorp.com.pg>
Message-ID: <9A755D79-C5CE-490A-A094-D692FF77EEDD@verizon.net>

wondering why the domain functions at all?   Just use =sum(), etc.   

Jim

Sent from my iPhone

On Aug 28, 2014, at 8:14 PM, "Stuart McLachlan" <stuart at lexacorp.com.pg> wrote:

> Do you have an appropriate index on the field(s) being aggregated? I suspect not.
> 
> On 28 Aug 2014 at 22:27, McGillivray, Don wrote:
> 
>> Hi Listers,
>> 
>> I have a form in an Access application (users have the Access 2010
>> runtime only, on Win 7;  Split FE/BE, with BE on network share) where
>> I need to display and continuously evaluate the cumulative count and
>> value of items and assign an incrementing serial number to child
>> records as they are entered.  At this point, the form uses domain
>> aggregate functions to determine the count and sum of the
>> transactions, and the max plus 1 for the next serial number.  At
>> modest volumes (<=200 records) performance is acceptable.  Beyond
>> that, performance becomes increasingly degraded, to the point of being
>> almost unusable by the time 400 records have been entered.
>> 
>> Obviously, the domain aggregate approach is not working for this
>> situation, so I'm looking for more efficient approaches to fulfill the
>> aggregating/incrementing requirements.  Can anybody point me in a
>> better direction?
>> 
>> Thanks!
>> 
>> Don McGillivray
>> 
>> ----------------------------------------------------------------------
>> ----- For those interested in further detail, please read on . . .
>> 
>> The application records customer payment data.  Ultimately, the
>> payment data collected by the system will be imported into an Oracle
>> database.  The payments, each consisting of a header record and one or
>> more GL distribution records, are entered in batches that correspond
>> to daily bank deposits.  The payment header record contains the
>> payment date, check number, and amount, and the GL distribution record
>> contains line item detail including an application number and the GL
>> account to which the revenue is booked.  Data entry begins with the
>> creation of a batch (deposit) header record that includes the date,
>> number of payments, number of applications paid for, and total deposit
>> amount.  (The item count and amount are used as "target" values during
>> data entry to ensure that everything balances in the end.)  Once the
>> batch header record is complete, the payment records are entered one
>> at a time, along with their GL details.  So I have a simple hierarchy
>> of data entities: Deposit !
>> Header - Payment Header - Payment Details, and the entry form is
>> designed (main form, sub-form, sub-form) to accommodate this
>> structure.  That's the quick and dirty description of the basic
>> setup.
>> 
>> A further wrinkle is that each payment record (child of the top level)
>> is associated to one or more stamp numbers that are affixed to the
>> check upon receipt, and those numbers must be included in the
>> distribution records (grandchildren to the top level) for each
>> payment.  The stamp numbers are composed of a date string (YYMMDD)
>> followed by an incrementing serial number from 1 to n each day,
>> according to the number of applications being paid for.  So, based on
>> the application count of the batch header, a list of stamp numbers can
>> be generated for each batch, and, assuming the checks are entered in
>> stamp number order, the next available number may be assigned
>> automatically to each payment until all are used up.  The entry form
>> allows the user to select from a combo box any valid stamp number for
>> any payment if necessary, but the typical scenario is to allow the
>> system to assign the numbers in sequence to the distribution records
>> automatically.
>> 
>> To help ensure accurate data entry, the user is required to have
>> entered values that agree with the target values.  For example, on a
>> given payment, before a new payment may be entered, the value of the
>> distribution records must equal the check amount as entered in the
>> payment header.  Similarly, the batch itself may not be posted until
>> the sum of its payment records equals the previously entered batch
>> totals (item count and amount.)  These rules are enforced by the form
>> by comparing the batch and payment header entries to the sums of the
>> line items as data is entered.
>> 
>> The application has been in production since May, and has functioned
>> well as designed.  However, this week an unusually large volume of
>> payments (>600) arrived on a single day, and as the batch entry
>> progressed beyond about 300 records, the form's performance became
>> increasingly degraded, until it was essentially unusable.  The
>> degradation is probably due to the methods I've employed to determine
>> the next available stamp number, compounded by the tabulation of the
>> item count and cumulative total for the batch as data entry
>> progresses.  In both cases, I'm using domain aggregate functions to
>> return the count and sum of payments entered, along with the max plus
>> 1 for the next available stamp number.  As the number of records in
>> the batch grows, these calculations take longer and longer.  The
>> effect was observed during development, leading me to modify the table
>> structure so that new records land in temporary tables before being
>> posted by the user to the permanent ones.  This im!
>> proved things quite a bit by avoiding the impact of aggregating over
>> a table whose content continues to grow over time, but apparently
>> that move is not enough when the batch volume rises beyond a certain
>> point.
>> -- 
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
> 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com


From bensonforums at gmail.com  Thu Aug 28 21:40:55 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 28 Aug 2014 22:40:55 -0400
Subject: [AccessD] Delete Query with a join
In-Reply-To: <CAMhYZWbUL-gBmsAPh+6SQ1sSoR_oZ0AyUuxcjL0MchS_1HKuzA@mail.gmail.com>
References: <CAMhYZWbUL-gBmsAPh+6SQ1sSoR_oZ0AyUuxcjL0MchS_1HKuzA@mail.gmail.com>
Message-ID: <CAJLzs_2ZY1YnYmwA2GWL7Vm0SLQARup-Jh2y+th=SYgt+DNfyQ@mail.gmail.com>

Try

   DELETE [rpt_DMHClaim 14].*
   FROM [rpt_DMHClaim 14]
WHERE Exists
   (SELECT 1
    FROM [qry 01a rpt_DMHClaim 14 Dupes to be > deleted]
    WHERE [qry 01a rpt_DMHClaim 14 Dupes to be > deleted].ClaimNumber =
[rpt_DMHClaim 14].ClaimNumber
AND
  [qry 01a rpt_DMHClaim 14 Dupes to be > deleted].MaxOfEOB_ID =
[rpt_DMHClaim 14].EOB_ID)

Action queries don't much like joins ad even distinctrow can lead to
duplicates no? Not sure really.

Got that here:
http://stackoverflow.com/questions/5585732/how-to-delete-in-ms-access-when-using-joins

From bensonforums at gmail.com  Thu Aug 28 21:49:41 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Thu, 28 Aug 2014 22:49:41 -0400
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <004201cfc213$38f289e0$aad79da0$@cox.net>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
	<004201cfc213$38f289e0$aad79da0$@cox.net>
Message-ID: <CAJLzs_2sSxV8VMh2+Xz-r=uYkzHNhSJTWRPy3Xk+orN1f_gUJg@mail.gmail.com>

I used CDO a long time ago to send SMTP emails from GE to wherever. I never
got any items to verify however, like I can get through Outlook (a copy in
the Sent Items folder)...

So if CDO uses GMAIL, I imagine it mails through the person's account. Will
a copy then be in the Gmail Sent Items folder?

Can contents in that folder be checked with VBA and or other 3rd party
tools?

It was always unsettling to me running a routine I could not go to. Sent
folder to verify whether and what was sent.

From gustav at cactus.dk  Fri Aug 29 01:34:07 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Fri, 29 Aug 2014 06:34:07 +0000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <CAJLzs_2sSxV8VMh2+Xz-r=uYkzHNhSJTWRPy3Xk+orN1f_gUJg@mail.gmail.com>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
	<004201cfc213$38f289e0$aad79da0$@cox.net>
	<CAJLzs_2sSxV8VMh2+Xz-r=uYkzHNhSJTWRPy3Xk+orN1f_gUJg@mail.gmail.com>
Message-ID: <8f8572bdc21e4207aa2318a2c6df306d@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Bill

An SMTP server normally doesn't leave copies, so I doubt the SMTP service of Gmail does.
But you can always add the sender as BCC.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
Sendt: 29. august 2014 04:50
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] A2003: Connecting with GMAIL

I used CDO a long time ago to send SMTP emails from GE to wherever. I never got any items to verify however, like I can get through Outlook (a copy in the Sent Items folder)...

So if CDO uses GMAIL, I imagine it mails through the person's account. Will a copy then be in the Gmail Sent Items folder?

Can contents in that folder be checked with VBA and or other 3rd party tools?

It was always unsettling to me running a routine I could not go to. Sent folder to verify whether and what was sent.
-- 


From stuart at lexacorp.com.pg  Fri Aug 29 02:08:32 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 29 Aug 2014 17:08:32 +1000
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <8f8572bdc21e4207aa2318a2c6df306d@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>,
	<CAJLzs_2sSxV8VMh2+Xz-r=uYkzHNhSJTWRPy3Xk+orN1f_gUJg@mail.gmail.com>,
	<8f8572bdc21e4207aa2318a2c6df306d@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <540026F0.32169.1CE96C43@stuart.lexacorp.com.pg>

Yep, that's a common way of doing it in this sort of situation (that's what a lot of Android email 
applications on phones/tablets do).

-- 
Stuart

On 29 Aug 2014 at 6:34, Gustav Brock wrote:

> Hi Bill
> 
> An SMTP server normally doesn't leave copies, so I doubt the SMTP
> service of Gmail does. But you can always add the sender as BCC.
> 
> /gustav
> 
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> Sendt: 29. august 2014 04:50 Til: Access Developers discussion and
> problem solving Emne: Re: [AccessD] A2003: Connecting with GMAIL
> 
> I used CDO a long time ago to send SMTP emails from GE to wherever. I
> never got any items to verify however, like I can get through Outlook
> (a copy in the Sent Items folder)...
> 
> So if CDO uses GMAIL, I imagine it mails through the person's account.
> Will a copy then be in the Gmail Sent Items folder?
> 
> Can contents in that folder be checked with VBA and or other 3rd party
> tools?
> 
> It was always unsettling to me running a routine I could not go to.
> Sent folder to verify whether and what was sent. -- 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 




From bensonforums at gmail.com  Fri Aug 29 02:36:57 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 29 Aug 2014 03:36:57 -0400
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <8f8572bdc21e4207aa2318a2c6df306d@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>
	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>
	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>
	<004201cfc213$38f289e0$aad79da0$@cox.net>
	<CAJLzs_2sSxV8VMh2+Xz-r=uYkzHNhSJTWRPy3Xk+orN1f_gUJg@mail.gmail.com>
	<8f8572bdc21e4207aa2318a2c6df306d@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CAJLzs_2z0Koiu3dTcRpD1EM5UJj2VjAojieOS0dxOr8LfOH=6A@mail.gmail.com>

Thanks. Yes, that is what I had ended up doing. I was just curious with
GMAIL because, well, they have those primary labels (folders) and I thought
it might be an inescapable feature of the GMAIL service that any item being
sent from a GMAIL account - by any means including CDO - would cause GMAIL
to show such sent item in the Sent Items folder.

I will try this eventually.
On Aug 29, 2014 2:37 AM, "Gustav Brock" <gustav at cactus.dk> wrote:

> Hi Bill
>
> An SMTP server normally doesn't leave copies, so I doubt the SMTP service
> of Gmail does.
> But you can always add the sender as BCC.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com [mailto:
> accessd-bounces at databaseadvisors.com] P? vegne af Bill Benson
> Sendt: 29. august 2014 04:50
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] A2003: Connecting with GMAIL
>
> I used CDO a long time ago to send SMTP emails from GE to wherever. I
> never got any items to verify however, like I can get through Outlook (a
> copy in the Sent Items folder)...
>
> So if CDO uses GMAIL, I imagine it mails through the person's account.
> Will a copy then be in the Gmail Sent Items folder?
>
> Can contents in that folder be checked with VBA and or other 3rd party
> tools?
>
> It was always unsettling to me running a routine I could not go to. Sent
> folder to verify whether and what was sent.
> --
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From jimdettman at verizon.net  Fri Aug 29 08:02:35 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Fri, 29 Aug 2014 09:02:35 -0400
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
Message-ID: <98BF9315F59D43B2A908E074F4BB868B@XPS>

Don,

  Just to add a bit to my post from last night as I couldn't see this
original post, you've got to be careful where you use Domain functions.

  What they do is just wrap up a SQL Statement so you can execute SQL in
places where you ordinarily can not.   For example, Dlookup() is "SELECT <x>
FROM <y> WHERE <Z>".    So any place you can use SQL directly you should and
a domain function is not appropriate.

 For example, totaling a field in a sub form.   Just place a control in the
footer and set its control source to:  =Sum(<expression>)

 One place where domain functions are really a no-no is inside of a query.
They are totally un-optimizable by the query processor and you are
guaranteeing yourself poor performance for anything over a couple of hundred
records. 

 Alternatives are executing SQL in code, performing operations on a record
set directly, etc.    

 Domain functions are handy to use, but in general, you'll find that you
don't use them often because there are other ways to do things.

Jim.



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don
Sent: Thursday, August 28, 2014 06:28 PM
To: accessD at databaseadvisors.com
Subject: [AccessD] Alternatives to domain aggregate functions

Hi Listers,

I have a form in an Access application (users have the Access 2010 runtime
only, on Win 7;  Split FE/BE, with BE on network share) where I need to
display and continuously evaluate the cumulative count and value of items
and assign an incrementing serial number to child records as they are
entered.  At this point, the form uses domain aggregate functions to
determine the count and sum of the transactions, and the max plus 1 for the
next serial number.  At modest volumes (<=200 records) performance is
acceptable.  Beyond that, performance becomes increasingly degraded, to the
point of being almost unusable by the time 400 records have been entered.

Obviously, the domain aggregate approach is not working for this situation,
so I'm looking for more efficient approaches to fulfill the
aggregating/incrementing requirements.  Can anybody point me in a better
direction?

Thanks!

Don McGillivray

---------------------------------------------------------------------------
For those interested in further detail, please read on . . .

The application records customer payment data.  Ultimately, the payment data
collected by the system will be imported into an Oracle database.  The
payments, each consisting of a header record and one or more GL distribution
records, are entered in batches that correspond to daily bank deposits.  The
payment header record contains the payment date, check number, and amount,
and the GL distribution record contains line item detail including an
application number and the GL account to which the revenue is booked.  Data
entry begins with the creation of a batch (deposit) header record that
includes the date, number of payments, number of applications paid for, and
total deposit amount.  (The item count and amount are used as "target"
values during data entry to ensure that everything balances in the end.)
Once the batch header record is complete, the payment records are entered
one at a time, along with their GL details.  So I have a simple hierarchy of
data entities: Deposit !
 Header - Payment Header - Payment Details, and the entry form is designed
(main form, sub-form, sub-form) to accommodate this structure.  That's the
quick and dirty description of the basic setup.

A further wrinkle is that each payment record (child of the top level) is
associated to one or more stamp numbers that are affixed to the check upon
receipt, and those numbers must be included in the distribution records
(grandchildren to the top level) for each payment.  The stamp numbers are
composed of a date string (YYMMDD) followed by an incrementing serial number
from 1 to n each day, according to the number of applications being paid
for.  So, based on the application count of the batch header, a list of
stamp numbers can be generated for each batch, and, assuming the checks are
entered in stamp number order, the next available number may be assigned
automatically to each payment until all are used up.  The entry form allows
the user to select from a combo box any valid stamp number for any payment
if necessary, but the typical scenario is to allow the system to assign the
numbers in sequence to the distribution records automatically.

To help ensure accurate data entry, the user is required to have entered
values that agree with the target values.  For example, on a given payment,
before a new payment may be entered, the value of the distribution records
must equal the check amount as entered in the payment header.  Similarly,
the batch itself may not be posted until the sum of its payment records
equals the previously entered batch totals (item count and amount.)  These
rules are enforced by the form by comparing the batch and payment header
entries to the sums of the line items as data is entered.

The application has been in production since May, and has functioned well as
designed.  However, this week an unusually large volume of payments (>600)
arrived on a single day, and as the batch entry progressed beyond about 300
records, the form's performance became increasingly degraded, until it was
essentially unusable.  The degradation is probably due to the methods I've
employed to determine the next available stamp number, compounded by the
tabulation of the item count and cumulative total for the batch as data
entry progresses.  In both cases, I'm using domain aggregate functions to
return the count and sum of payments entered, along with the max plus 1 for
the next available stamp number.  As the number of records in the batch
grows, these calculations take longer and longer.  The effect was observed
during development, leading me to modify the table structure so that new
records land in temporary tables before being posted by the user to the
permanent ones.  This im!
 proved things quite a bit by avoiding the impact of aggregating over a
table whose content continues to grow over time, but apparently that move is
not enough when the batch volume rises beyond a certain point.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 08:07:25 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 09:07:25 -0400
Subject: [AccessD] Normalization discussion
Message-ID: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>

I'll spend the morning rereading the book Martin and I wrote, brushing up
on the normalization part. I've forgotten a lot of the basics. I'm writing
an animal tracing database in Access and I'm trying to remember if it
matters where the fk goes. Now, I remember its purpose and all that, but it
would be so much simpler if I could just drop them all into the main table
instead of adding a fk to all the child tables to the main table -- I think
anyway.

So, I've got a main table of animals and all of the remaining tables are
child tables of a sort and a few lookup tables. Is it reasonable to just
add a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10
years? It's been long enough that I'm really struggling.

Susan H.

From rockysmolin at bchacc.com  Fri Aug 29 08:14:07 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 29 Aug 2014 06:14:07 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
Message-ID: <13379C5FA88B4E479196F17EEADF804B@HAL9007>

"Is it reasonable to just add a fk to all those child tables in my parent
table?"  More than reasonable, IMO.  Makes life easy in the front end.

Again, if you need any help, please contact me off line.  Be happy to do it.

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 6:07 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Normalization discussion

I'll spend the morning rereading the book Martin and I wrote, brushing up on
the normalization part. I've forgotten a lot of the basics. I'm writing an
animal tracing database in Access and I'm trying to remember if it matters
where the fk goes. Now, I remember its purpose and all that, but it would be
so much simpler if I could just drop them all into the main table instead of
adding a fk to all the child tables to the main table -- I think anyway.

So, I've got a main table of animals and all of the remaining tables are
child tables of a sort and a few lookup tables. Is it reasonable to just add
a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10
years? It's been long enough that I'm really struggling.

Susan H.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 08:21:12 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 14:21:12 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAOGjT3cxwMRKk6LyJ1LeIhMBAAAAAA==@blueyonder.co.uk>

That does assume that, if the FK is to point to a unique PK, then the child rows
are ONLY associated with a single row of the Parent.

As I've found out that is not always the case!
As in with animals there is genus and specific breed, as well as just locale or
sexual differentiation 

JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 2:07 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Normalization discussion

I'll spend the morning rereading the book Martin and I wrote, brushing up
on the normalization part. I've forgotten a lot of the basics. I'm writing
an animal tracing database in Access and I'm trying to remember if it
matters where the fk goes. Now, I remember its purpose and all that, but it
would be so much simpler if I could just drop them all into the main table
instead of adding a fk to all the child tables to the main table -- I think
anyway.

So, I've got a main table of animals and all of the remaining tables are
child tables of a sort and a few lookup tables. Is it reasonable to just
add a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10
years? It's been long enough that I'm really struggling.

Susan H.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 08:37:52 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 09:37:52 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAOGjT3cxwMRKk6LyJ1LeIhMBAAAAAA==@blueyonder.co.uk>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAOGjT3cxwMRKk6LyJ1LeIhMBAAAAAA==@blueyonder.co.uk>
Message-ID: <CA++Sg+d+0T739uN4cz7GiJg1TtHFto00Q_sKJNep+asgvmPxwg@mail.gmail.com>

Everything is mostly one to one, with a few one to many -- haven't run into
a single many to many yet. This should be a simple shut-and-dry db, but I
just don't remember how to use Access anymore. Can I blame it on old-timers
disease?

The parent table will list each animal by name and species. Beyond that,
we'll track its acquisition (three different ways to acquire them), their
general health, diet, and so on. But everything leads back to the
individual animal.

I have the tables in and then my brain shuts down. It's not like riding a
bike apparently... :)


Susan H.


On Fri, Aug 29, 2014 at 9:21 AM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

> That does assume that, if the FK is to point to a unique PK, then the
> child rows
> are ONLY associated with a single row of the Parent.
>
> As I've found out that is not always the case!
> As in with animals there is genus and specific breed, as well as just
> locale or
> sexual differentiation
>
> JimB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 2:07 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Normalization discussion
>
> I'll spend the morning rereading the book Martin and I wrote, brushing up
> on the normalization part. I've forgotten a lot of the basics. I'm writing
> an animal tracing database in Access and I'm trying to remember if it
> matters where the fk goes. Now, I remember its purpose and all that, but it
> would be so much simpler if I could just drop them all into the main table
> instead of adding a fk to all the child tables to the main table -- I think
> anyway.
>
> So, I've got a main table of animals and all of the remaining tables are
> child tables of a sort and a few lookup tables. Is it reasonable to just
> add a fk to all those child tables in my parent table?
>
> I just don't remember. I haven't built a database in... seriously... 10
> years? It's been long enough that I'm really struggling.
>
> Susan H.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From ssharkins at gmail.com  Fri Aug 29 08:38:22 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 09:38:22 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <13379C5FA88B4E479196F17EEADF804B@HAL9007>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<13379C5FA88B4E479196F17EEADF804B@HAL9007>
Message-ID: <CA++Sg+eOuVR38+NZKHejMujOOCsg5AYQh9En38NhLjQoB+QS9g@mail.gmail.com>

Thank you Rocky. I know you mean that. :) You could have this thing written
in about 3 hours I imagine. :)

Susan H.


On Fri, Aug 29, 2014 at 9:14 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> "Is it reasonable to just add a fk to all those child tables in my parent
> table?"  More than reasonable, IMO.  Makes life easy in the front end.
>
> Again, if you need any help, please contact me off line.  Be happy to do
> it.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 6:07 AM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Normalization discussion
>
> I'll spend the morning rereading the book Martin and I wrote, brushing up
> on
> the normalization part. I've forgotten a lot of the basics. I'm writing an
> animal tracing database in Access and I'm trying to remember if it matters
> where the fk goes. Now, I remember its purpose and all that, but it would
> be
> so much simpler if I could just drop them all into the main table instead
> of
> adding a fk to all the child tables to the main table -- I think anyway.
>
> So, I've got a main table of animals and all of the remaining tables are
> child tables of a sort and a few lookup tables. Is it reasonable to just
> add
> a fk to all those child tables in my parent table?
>
> I just don't remember. I haven't built a database in... seriously... 10
> years? It's been long enough that I'm really struggling.
>
> Susan H.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From gustav at cactus.dk  Fri Aug 29 08:40:37 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Fri, 29 Aug 2014 13:40:37 +0000
Subject: [AccessD] Normalization discussion
Message-ID: <85f8475aee3b496b8f6d3ea3801df34f@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Susan

Good to see you back on the horse!

I'm not "strong in animals" so I hardly can add anything that you can't read in the book.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Susan Harkins
Sendt: 29. august 2014 15:07
Til: Access Developers discussion and problem solving
Emne: [AccessD] Normalization discussion

I'll spend the morning rereading the book Martin and I wrote, brushing up on the normalization part. I've forgotten a lot of the basics. I'm writing an animal tracing database in Access and I'm trying to remember if it matters where the fk goes. Now, I remember its purpose and all that, but it would be so much simpler if I could just drop them all into the main table instead of adding a fk to all the child tables to the main table -- I think anyway.

So, I've got a main table of animals and all of the remaining tables are child tables of a sort and a few lookup tables. Is it reasonable to just add a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10 years? It's been long enough that I'm really struggling.

Susan H. 


From jimdettman at verizon.net  Fri Aug 29 09:00:40 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Fri, 29 Aug 2014 10:00:40 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
Message-ID: <DB65F595BD1743E49093C302DCA6D34F@XPS>


 I think you've got what your saying is the parent and child tables mixed
up, which is why it's confusing.

 A FK always goes in the child table.

  So if I have tblBreeds and tblAnimals, Breeds is the parent table and the
PK from that would go in tblAnimals as a FK so you'd know what specific
breed a particular animal was.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 09:07 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Normalization discussion

I'll spend the morning rereading the book Martin and I wrote, brushing up
on the normalization part. I've forgotten a lot of the basics. I'm writing
an animal tracing database in Access and I'm trying to remember if it
matters where the fk goes. Now, I remember its purpose and all that, but it
would be so much simpler if I could just drop them all into the main table
instead of adding a fk to all the child tables to the main table -- I think
anyway.

So, I've got a main table of animals and all of the remaining tables are
child tables of a sort and a few lookup tables. Is it reasonable to just
add a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10
years? It's been long enough that I'm really struggling.

Susan H.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 09:08:57 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 15:08:57 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAOGjT3cxwMRKk6LyJ1LeIhMBAAAAAA==@blueyonder.co.uk>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAOGjT3cxwMRKk6LyJ1LeIhMBAAAAAA==@blueyonder.co.uk>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAP2dRH2UPf5AtTXNsnmWcYoBAAAAAA==@blueyonder.co.uk>

I'd say 
Don't worry about normalisation -
Just consider the use of the data  and group it as appropriate 
Primary table would, I presume be the animal's id code as registered with the
worldwide (or if appropriate local) registration authority.

>From there it's split the data into sets that fit your mental comprehension,
having multiple tables as needed where there may be commonality in animals, or
where the entries apply to a specific set - as in registration details with an
appropriate authority  where perhaps 10% of them are associated with that
authority, and where a different registration authority wants a substantially
different set of data

Then allow for animals to leave, and return, maybe remaining under your
registration, and maybe getting a different id while they were away and when
they come back
 
Basically adjust the structure from strict normalisation to fit the forms and
reports that Access will setup for you. 

JimB


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button
Sent: Friday, August 29, 2014 2:21 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Normalization discussion

That does assume that, if the FK is to point to a unique PK, then the child rows
are ONLY associated with a single row of the Parent.

As I've found out that is not always the case!
As in with animals there is genus and specific breed, as well as just locale or
sexual differentiation 

JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 2:07 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] Normalization discussion

I'll spend the morning rereading the book Martin and I wrote, brushing up
on the normalization part. I've forgotten a lot of the basics. I'm writing
an animal tracing database in Access and I'm trying to remember if it
matters where the fk goes. Now, I remember its purpose and all that, but it
would be so much simpler if I could just drop them all into the main table
instead of adding a fk to all the child tables to the main table -- I think
anyway.

So, I've got a main table of animals and all of the remaining tables are
child tables of a sort and a few lookup tables. Is it reasonable to just
add a fk to all those child tables in my parent table?

I just don't remember. I haven't built a database in... seriously... 10
years? It's been long enough that I'm really struggling.

Susan H.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From charlotte.foust at gmail.com  Fri Aug 29 09:18:14 2014
From: charlotte.foust at gmail.com (Charlotte Foust)
Date: Fri, 29 Aug 2014 07:18:14 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
Message-ID: <CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>

A foreign key is a key that points to the PK in another table.  You're
mixing keys with parent child relationships, which are defined through
keys.  In a data warehouse, you put a bunch of keys in the central table,
but in a regular database you put the parent PK into the child tables so
they know their mommy,  The idea is to put the keys where they are needed.

Charlotte


On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> I'll spend the morning rereading the book Martin and I wrote, brushing up
> on the normalization part. I've forgotten a lot of the basics. I'm writing
> an animal tracing database in Access and I'm trying to remember if it
> matters where the fk goes. Now, I remember its purpose and all that, but it
> would be so much simpler if I could just drop them all into the main table
> instead of adding a fk to all the child tables to the main table -- I think
> anyway.
>
> So, I've got a main table of animals and all of the remaining tables are
> child tables of a sort and a few lookup tables. Is it reasonable to just
> add a fk to all those child tables in my parent table?
>
> I just don't remember. I haven't built a database in... seriously... 10
> years? It's been long enough that I'm really struggling.
>
> Susan H.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From fuller.artful at gmail.com  Fri Aug 29 10:00:13 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 29 Aug 2014 11:00:13 -0400
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <98BF9315F59D43B2A908E074F4BB868B@XPS>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<98BF9315F59D43B2A908E074F4BB868B@XPS>
Message-ID: <CAEPJO1i3G=JsZ6rC_pGxmDfyUyR3VV_z66tDguwAowc+GK87Nw@mail.gmail.com>

Jim.

Excellent summary, and I would add a couple of points:

If at all possible, lose the Access Back End (BE) and replace it with
either the free edition of MS-SQL or MySQL or MariaDb. In all cases the
increase in performance is significant, and many times dramatic. Basically,
the larger the number of users, the more dramatic the increase in
performance.

Having made that move, then the next logical place to go is Stored
Procedures rather than Access queries. In my many years as a developer, I
have seen very few occasions where dynamic construction of a SQL query was
the only solution. About 99% of the time, it is unnecessary. A little
thought and the use of optional parameters to an SP is the better way.

Arthur


On Fri, Aug 29, 2014 at 9:02 AM, Jim Dettman <jimdettman at verizon.net> wrote:

> Don,
>
>   Just to add a bit to my post from last night as I couldn't see this
> original post, you've got to be careful where you use Domain functions.
>
>   What they do is just wrap up a SQL Statement so you can execute SQL in
> places where you ordinarily can not.   For example, Dlookup() is "SELECT
> <x>
> FROM <y> WHERE <Z>".    So any place you can use SQL directly you should
> and
> a domain function is not appropriate.
>
>  For example, totaling a field in a sub form.   Just place a control in the
> footer and set its control source to:  =Sum(<expression>)
>
>  One place where domain functions are really a no-no is inside of a query.
> They are totally un-optimizable by the query processor and you are
> guaranteeing yourself poor performance for anything over a couple of
> hundred
> records.
>
>  Alternatives are executing SQL in code, performing operations on a record
> set directly, etc.
>
>  Domain functions are handy to use, but in general, you'll find that you
> don't use them often because there are other ways to do things.
>
> Jim.
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray,
> Don
> Sent: Thursday, August 28, 2014 06:28 PM
> To: accessD at databaseadvisors.com
> Subject: [AccessD] Alternatives to domain aggregate functions
>
> Hi Listers,
>
> I have a form in an Access application (users have the Access 2010 runtime
> only, on Win 7;  Split FE/BE, with BE on network share) where I need to
> display and continuously evaluate the cumulative count and value of items
> and assign an incrementing serial number to child records as they are
> entered.  At this point, the form uses domain aggregate functions to
> determine the count and sum of the transactions, and the max plus 1 for the
> next serial number.  At modest volumes (<=200 records) performance is
> acceptable.  Beyond that, performance becomes increasingly degraded, to the
> point of being almost unusable by the time 400 records have been entered.
>
> Obviously, the domain aggregate approach is not working for this situation,
> so I'm looking for more efficient approaches to fulfill the
> aggregating/incrementing requirements.  Can anybody point me in a better
> direction?
>
> Thanks!
>
> Don McGillivray
>
> ---------------------------------------------------------------------------
> For those interested in further detail, please read on . . .
>
> The application records customer payment data.  Ultimately, the payment
> data
> collected by the system will be imported into an Oracle database.  The
> payments, each consisting of a header record and one or more GL
> distribution
> records, are entered in batches that correspond to daily bank deposits.
> The
> payment header record contains the payment date, check number, and amount,
> and the GL distribution record contains line item detail including an
> application number and the GL account to which the revenue is booked.  Data
> entry begins with the creation of a batch (deposit) header record that
> includes the date, number of payments, number of applications paid for, and
> total deposit amount.  (The item count and amount are used as "target"
> values during data entry to ensure that everything balances in the end.)
> Once the batch header record is complete, the payment records are entered
> one at a time, along with their GL details.  So I have a simple hierarchy
> of
> data entities: Deposit !
>  Header - Payment Header - Payment Details, and the entry form is designed
> (main form, sub-form, sub-form) to accommodate this structure.  That's the
> quick and dirty description of the basic setup.
>
> A further wrinkle is that each payment record (child of the top level) is
> associated to one or more stamp numbers that are affixed to the check upon
> receipt, and those numbers must be included in the distribution records
> (grandchildren to the top level) for each payment.  The stamp numbers are
> composed of a date string (YYMMDD) followed by an incrementing serial
> number
> from 1 to n each day, according to the number of applications being paid
> for.  So, based on the application count of the batch header, a list of
> stamp numbers can be generated for each batch, and, assuming the checks are
> entered in stamp number order, the next available number may be assigned
> automatically to each payment until all are used up.  The entry form allows
> the user to select from a combo box any valid stamp number for any payment
> if necessary, but the typical scenario is to allow the system to assign the
> numbers in sequence to the distribution records automatically.
>
> To help ensure accurate data entry, the user is required to have entered
> values that agree with the target values.  For example, on a given payment,
> before a new payment may be entered, the value of the distribution records
> must equal the check amount as entered in the payment header.  Similarly,
> the batch itself may not be posted until the sum of its payment records
> equals the previously entered batch totals (item count and amount.)  These
> rules are enforced by the form by comparing the batch and payment header
> entries to the sums of the line items as data is entered.
>
> The application has been in production since May, and has functioned well
> as
> designed.  However, this week an unusually large volume of payments (>600)
> arrived on a single day, and as the batch entry progressed beyond about 300
> records, the form's performance became increasingly degraded, until it was
> essentially unusable.  The degradation is probably due to the methods I've
> employed to determine the next available stamp number, compounded by the
> tabulation of the item count and cumulative total for the batch as data
> entry progresses.  In both cases, I'm using domain aggregate functions to
> return the count and sum of payments entered, along with the max plus 1 for
> the next available stamp number.  As the number of records in the batch
> grows, these calculations take longer and longer.  The effect was observed
> during development, leading me to modify the table structure so that new
> records land in temporary tables before being posted by the user to the
> permanent ones.  This im!
>  proved things quite a bit by avoiding the impact of aggregating over a
> table whose content continues to grow over time, but apparently that move
> is
> not enough when the batch volume rises beyond a certain point.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur

From ssharkins at gmail.com  Fri Aug 29 10:39:10 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 11:39:10 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
Message-ID: <CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>

Right now, most of my foreign keys in the parent table are simple lookups.
For instance, species -- each individual has a species and those are in a
child table. We'll update that table infrequently -- only if we add a new
species. We have several individuals of each species. Another is gender --
female and male, but the parent table has a foreign key to the gender
table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
tracking acquisition method -- there are only three, so again, it's a
lookup table and not a true child table.

Susan H.








On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <charlotte.foust at gmail.com
> wrote:

> A foreign key is a key that points to the PK in another table.  You're
> mixing keys with parent child relationships, which are defined through
> keys.  In a data warehouse, you put a bunch of keys in the central table,
> but in a regular database you put the parent PK into the child tables so
> they know their mommy,  The idea is to put the keys where they are needed.
>
> Charlotte
>
>
> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > I'll spend the morning rereading the book Martin and I wrote, brushing up
> > on the normalization part. I've forgotten a lot of the basics. I'm
> writing
> > an animal tracing database in Access and I'm trying to remember if it
> > matters where the fk goes. Now, I remember its purpose and all that, but
> it
> > would be so much simpler if I could just drop them all into the main
> table
> > instead of adding a fk to all the child tables to the main table -- I
> think
> > anyway.
> >
> > So, I've got a main table of animals and all of the remaining tables are
> > child tables of a sort and a few lookup tables. Is it reasonable to just
> > add a fk to all those child tables in my parent table?
> >
> > I just don't remember. I haven't built a database in... seriously... 10
> > years? It's been long enough that I'm really struggling.
> >
> > Susan H.
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From dw-murphy at cox.net  Fri Aug 29 10:47:55 2014
From: dw-murphy at cox.net (Doug Murphy)
Date: Fri, 29 Aug 2014 08:47:55 -0700
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <kSqv1o0100xgD8Z01SqxTL>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>	<004201cfc213$38f289e0$aad79da0$@cox.net>
	<kSqv1o0100xgD8Z01SqxTL>
Message-ID: <003701cfc3a0$998074f0$cc815ed0$@cox.net>

CDO does not use any of the Outlook functionality. When you use the Google
SMTP server you need a Gmail account for the login/password. The sent emails
are in that accounts Sent Mail folder. Using the Google server works for
small mailings. There is a limit of something like 400 emails per day I
think. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Thursday, August 28, 2014 7:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

I used CDO a long time ago to send SMTP emails from GE to wherever. I never
got any items to verify however, like I can get through Outlook (a copy in
the Sent Items folder)...

So if CDO uses GMAIL, I imagine it mails through the person's account. Will
a copy then be in the Gmail Sent Items folder?

Can contents in that folder be checked with VBA and or other 3rd party
tools?

It was always unsettling to me running a routine I could not go to. Sent
folder to verify whether and what was sent.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 11:38:35 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 17:38:35 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAB0q2OsZc1FDs+OPWzaMrugBAAAAAA==@blueyonder.co.uk>

Child table is one where an entry cannot exist without the parent entry

As in you can define the species in a table without specifying the animals in
the species
So Species would be the PARENT of animals because 
An animal has to be within a species, but a species can have several animals in
it

Delete (exterminate) a species and you lose lots of animals 
Delete (exterminate) an animal and you still have others of the same species

JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 4:39 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

Right now, most of my foreign keys in the parent table are simple lookups.
For instance, species -- each individual has a species and those are in a
child table. We'll update that table infrequently -- only if we add a new
species. We have several individuals of each species. Another is gender --
female and male, but the parent table has a foreign key to the gender
table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
tracking acquisition method -- there are only three, so again, it's a
lookup table and not a true child table.

Susan H.








On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <charlotte.foust at gmail.com
> wrote:

> A foreign key is a key that points to the PK in another table.  You're
> mixing keys with parent child relationships, which are defined through
> keys.  In a data warehouse, you put a bunch of keys in the central table,
> but in a regular database you put the parent PK into the child tables so
> they know their mommy,  The idea is to put the keys where they are needed.
>
> Charlotte
>
>
> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > I'll spend the morning rereading the book Martin and I wrote, brushing up
> > on the normalization part. I've forgotten a lot of the basics. I'm
> writing
> > an animal tracing database in Access and I'm trying to remember if it
> > matters where the fk goes. Now, I remember its purpose and all that, but
> it
> > would be so much simpler if I could just drop them all into the main
> table
> > instead of adding a fk to all the child tables to the main table -- I
> think
> > anyway.
> >
> > So, I've got a main table of animals and all of the remaining tables are
> > child tables of a sort and a few lookup tables. Is it reasonable to just
> > add a fk to all those child tables in my parent table?
> >
> > I just don't remember. I haven't built a database in... seriously... 10
> > years? It's been long enough that I'm really struggling.
> >
> > Susan H.
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 12:39:21 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 13:39:21 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAB0q2OsZc1FDs+OPWzaMrugBAAAAAA==@blueyonder.co.uk>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAB0q2OsZc1FDs+OPWzaMrugBAAAAAA==@blueyonder.co.uk>
Message-ID: <CA++Sg+e0+tZH14RGyqPxFyQ2gZF5jradqvWYqZEOoSxmEBE+-g@mail.gmail.com>

But you're talking in broader terms. In this database, I'd not be tracking
species without the animals. I would have no reason whatsoever to track
species.

I'm listening because you make sense -- but I'm not certain what you've
said actually applies to what I'm doing. The animals are the parent table
-- everything in the database applies to an individual animal.

Susan H.


On Fri, Aug 29, 2014 at 12:38 PM, James Button <jamesbutton at blueyonder.co.uk
> wrote:

> Child table is one where an entry cannot exist without the parent entry
>
> As in you can define the species in a table without specifying the animals
> in
> the species
> So Species would be the PARENT of animals because
> An animal has to be within a species, but a species can have several
> animals in
> it
>
> Delete (exterminate) a species and you lose lots of animals
> Delete (exterminate) an animal and you still have others of the same
> species
>
> JimB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 4:39 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Normalization discussion
>
> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are in a
> child table. We'll update that table infrequently -- only if we add a new
> species. We have several individuals of each species. Another is gender --
> female and male, but the parent table has a foreign key to the gender
> table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
> tracking acquisition method -- there are only three, so again, it's a
> lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com
> > wrote:
>
> > A foreign key is a key that points to the PK in another table.  You're
> > mixing keys with parent child relationships, which are defined through
> > keys.  In a data warehouse, you put a bunch of keys in the central table,
> > but in a regular database you put the parent PK into the child tables so
> > they know their mommy,  The idea is to put the keys where they are
> needed.
> >
> > Charlotte
> >
> >
> > On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> > wrote:
> >
> > > I'll spend the morning rereading the book Martin and I wrote, brushing
> up
> > > on the normalization part. I've forgotten a lot of the basics. I'm
> > writing
> > > an animal tracing database in Access and I'm trying to remember if it
> > > matters where the fk goes. Now, I remember its purpose and all that,
> but
> > it
> > > would be so much simpler if I could just drop them all into the main
> > table
> > > instead of adding a fk to all the child tables to the main table -- I
> > think
> > > anyway.
> > >
> > > So, I've got a main table of animals and all of the remaining tables
> are
> > > child tables of a sort and a few lookup tables. Is it reasonable to
> just
> > > add a fk to all those child tables in my parent table?
> > >
> > > I just don't remember. I haven't built a database in... seriously... 10
> > > years? It's been long enough that I'm really struggling.
> > >
> > > Susan H.
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From bensonforums at gmail.com  Fri Aug 29 12:52:37 2014
From: bensonforums at gmail.com (Bill Benson)
Date: Fri, 29 Aug 2014 13:52:37 -0400
Subject: [AccessD] A2003: Connecting with GMAIL
In-Reply-To: <003701cfc3a0$998074f0$cc815ed0$@cox.net>
References: <53FD2855.29241.1136DB3D@stuart.lexacorp.com.pg>	<D8ECFC66AF654A0686CA8E5FD50931C2@DDNote>	<53FD3903.28658.117805F6@stuart.lexacorp.com.pg>	<004201cfc213$38f289e0$aad79da0$@cox.net>	<kSqv1o0100xgD8Z01SqxTL>
	<003701cfc3a0$998074f0$cc815ed0$@cox.net>
Message-ID: <0bc101cfc3b2$065b8590$131290b0$@gmail.com>

I did not mean to imply that CDO used Outlook, if I seemed to. I was just
asking what you answered in the last part of your response Doug. Thank you.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Friday, August 29, 2014 11:48 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] A2003: Connecting with GMAIL

CDO does not use any of the Outlook functionality. When you use the Google
SMTP server you need a Gmail account for the login/password. The sent emails
are in that accounts Sent Mail folder. Using the Google server works for
small mailings. There is a limit of something like 400 emails per day I
think. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
Sent: Thursday, August 28, 2014 7:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003: Connecting with GMAIL

I used CDO a long time ago to send SMTP emails from GE to wherever. I never
got any items to verify however, like I can get through Outlook (a copy in
the Sent Items folder)...

So if CDO uses GMAIL, I imagine it mails through the person's account. Will
a copy then be in the Gmail Sent Items folder?

Can contents in that folder be checked with VBA and or other 3rd party
tools?

It was always unsettling to me running a routine I could not go to. Sent
folder to verify whether and what was sent.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 12:53:40 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 13:53:40 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
Message-ID: <CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>

What I'm struggling with today is acquisitions. There are three ways that
we acquire an animal -- live birth here at the center, from an institution,
or through law enforcement confiscation (almost never happens, but I'm
allowing for the possibility). So, each animal has an acquisition type, but
depending on the type the subsequent data will be different. For example,
if a live birth here at the center, we will also track the dam and sire
ids. If we acquire an animal from an institution, we'll track the
institution's info, like name, address, phone, and a contact.

So, an animal has an acquisition id by type. It's easy to keep an
institution and live birth table -- that's no problem. But how do I relate
them back to the individual since it can come from two different tables? I
think this is probably easier than I'm making it.

Susan H.


On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are in a
> child table. We'll update that table infrequently -- only if we add a new
> species. We have several individuals of each species. Another is gender --
> female and male, but the parent table has a foreign key to the gender
> table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
> tracking acquisition method -- there are only three, so again, it's a
> lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com> wrote:
>
>> A foreign key is a key that points to the PK in another table.  You're
>> mixing keys with parent child relationships, which are defined through
>> keys.  In a data warehouse, you put a bunch of keys in the central table,
>> but in a regular database you put the parent PK into the child tables so
>> they know their mommy,  The idea is to put the keys where they are needed.
>>
>> Charlotte
>>
>>
>> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
>> wrote:
>>
>> > I'll spend the morning rereading the book Martin and I wrote, brushing
>> up
>> > on the normalization part. I've forgotten a lot of the basics. I'm
>> writing
>> > an animal tracing database in Access and I'm trying to remember if it
>> > matters where the fk goes. Now, I remember its purpose and all that,
>> but it
>> > would be so much simpler if I could just drop them all into the main
>> table
>> > instead of adding a fk to all the child tables to the main table -- I
>> think
>> > anyway.
>> >
>> > So, I've got a main table of animals and all of the remaining tables are
>> > child tables of a sort and a few lookup tables. Is it reasonable to just
>> > add a fk to all those child tables in my parent table?
>> >
>> > I just don't remember. I haven't built a database in... seriously... 10
>> > years? It's been long enough that I'm really struggling.
>> >
>> > Susan H.
>> > --
>> > AccessD mailing list
>> > AccessD at databaseadvisors.com
>> > http://databaseadvisors.com/mailman/listinfo/accessd
>> > Website: http://www.databaseadvisors.com
>> >
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>

From DMcGillivray at ctc.ca.gov  Fri Aug 29 12:57:38 2014
From: DMcGillivray at ctc.ca.gov (McGillivray, Don)
Date: Fri, 29 Aug 2014 17:57:38 +0000
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <53FFC5EA.8912.1B6E6A57@stuart.lexacorp.com.pg>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<53FFC5EA.8912.1B6E6A57@stuart.lexacorp.com.pg>
Message-ID: <E48E6D791ED38E4BA54107C702704247131234A3@hqex01.ctc.ca.gov>

Hi Stuart,

I think you're right.  I have defined additional indexes on the table and will do a load test using the new configuration.

Thanks for your response!

Don

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Thursday, August 28, 2014 5:15 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Alternatives to domain aggregate functions

Do you have an appropriate index on the field(s) being aggregated? I suspect not.

On 28 Aug 2014 at 22:27, McGillivray, Don wrote:

> Hi Listers,
> 
> I have a form in an Access application (users have the Access 2010 
> runtime only, on Win 7;  Split FE/BE, with BE on network share) where 
> I need to display and continuously evaluate the cumulative count and 
> value of items and assign an incrementing serial number to child 
> records as they are entered.  At this point, the form uses domain 
> aggregate functions to determine the count and sum of the 
> transactions, and the max plus 1 for the next serial number.  At 
> modest volumes (<=200 records) performance is acceptable.  Beyond 
> that, performance becomes increasingly degraded, to the point of being 
> almost unusable by the time 400 records have been entered.
> 
> Obviously, the domain aggregate approach is not working for this 
> situation, so I'm looking for more efficient approaches to fulfill the 
> aggregating/incrementing requirements.  Can anybody point me in a 
> better direction?
> 
> Thanks!
> 
> Don McGillivray
> 
> ----------------------------------------------------------------------
> ----- For those interested in further detail, please read on . . .
> 
> The application records customer payment data.  Ultimately, the 
> payment data collected by the system will be imported into an Oracle 
> database.  The payments, each consisting of a header record and one or 
> more GL distribution records, are entered in batches that correspond 
> to daily bank deposits.  The payment header record contains the 
> payment date, check number, and amount, and the GL distribution record 
> contains line item detail including an application number and the GL 
> account to which the revenue is booked.  Data entry begins with the 
> creation of a batch (deposit) header record that includes the date, 
> number of payments, number of applications paid for, and total deposit 
> amount.  (The item count and amount are used as "target" values during 
> data entry to ensure that everything balances in the end.)  Once the 
> batch header record is complete, the payment records are entered one 
> at a time, along with their GL details.  So I have a simple hierarchy 
> of data entities: Deposit !
>  Header - Payment Header - Payment Details, and the entry form is  
> designed (main form, sub-form, sub-form) to accommodate this  
> structure.  That's the quick and dirty description of the basic  
> setup.
> 
> A further wrinkle is that each payment record (child of the top level) 
> is associated to one or more stamp numbers that are affixed to the 
> check upon receipt, and those numbers must be included in the 
> distribution records (grandchildren to the top level) for each 
> payment.  The stamp numbers are composed of a date string (YYMMDD) 
> followed by an incrementing serial number from 1 to n each day, 
> according to the number of applications being paid for.  So, based on 
> the application count of the batch header, a list of stamp numbers can 
> be generated for each batch, and, assuming the checks are entered in 
> stamp number order, the next available number may be assigned 
> automatically to each payment until all are used up.  The entry form 
> allows the user to select from a combo box any valid stamp number for 
> any payment if necessary, but the typical scenario is to allow the 
> system to assign the numbers in sequence to the distribution records 
> automatically.
> 
> To help ensure accurate data entry, the user is required to have 
> entered values that agree with the target values.  For example, on a 
> given payment, before a new payment may be entered, the value of the 
> distribution records must equal the check amount as entered in the 
> payment header.  Similarly, the batch itself may not be posted until 
> the sum of its payment records equals the previously entered batch 
> totals (item count and amount.)  These rules are enforced by the form 
> by comparing the batch and payment header entries to the sums of the 
> line items as data is entered.
> 
> The application has been in production since May, and has functioned 
> well as designed.  However, this week an unusually large volume of 
> payments (>600) arrived on a single day, and as the batch entry 
> progressed beyond about 300 records, the form's performance became 
> increasingly degraded, until it was essentially unusable.  The 
> degradation is probably due to the methods I've employed to determine 
> the next available stamp number, compounded by the tabulation of the 
> item count and cumulative total for the batch as data entry 
> progresses.  In both cases, I'm using domain aggregate functions to 
> return the count and sum of payments entered, along with the max plus
> 1 for the next available stamp number.  As the number of records in 
> the batch grows, these calculations take longer and longer.  The 
> effect was observed during development, leading me to modify the table 
> structure so that new records land in temporary tables before being 
> posted by the user to the permanent ones.  This im!
>  proved things quite a bit by avoiding the impact of aggregating over  
> a table whose content continues to grow over time, but apparently  
> that move is not enough when the batch volume rises beyond a certain  
> point.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From DMcGillivray at ctc.ca.gov  Fri Aug 29 13:03:02 2014
From: DMcGillivray at ctc.ca.gov (McGillivray, Don)
Date: Fri, 29 Aug 2014 18:03:02 +0000
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <CAEPJO1i3G=JsZ6rC_pGxmDfyUyR3VV_z66tDguwAowc+GK87Nw@mail.gmail.com>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<98BF9315F59D43B2A908E074F4BB868B@XPS>
	<CAEPJO1i3G=JsZ6rC_pGxmDfyUyR3VV_z66tDguwAowc+GK87Nw@mail.gmail.com>
Message-ID: <E48E6D791ED38E4BA54107C702704247131234B7@hqex01.ctc.ca.gov>

Arthur,

I'm afraid using a different BE isn't going to be an option in our environment - at least not in the immediate future.  We are an Oracle shop, so I suppose there may be an opportunity to use that for the back end, but I doubt that I can get traction for adding another flavor of server-side DB to our mix.

Thanks for your suggestion.

Don

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Friday, August 29, 2014 8:00 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Alternatives to domain aggregate functions

Jim.

Excellent summary, and I would add a couple of points:

If at all possible, lose the Access Back End (BE) and replace it with either the free edition of MS-SQL or MySQL or MariaDb. In all cases the increase in performance is significant, and many times dramatic. Basically, the larger the number of users, the more dramatic the increase in performance.

Having made that move, then the next logical place to go is Stored Procedures rather than Access queries. In my many years as a developer, I have seen very few occasions where dynamic construction of a SQL query was the only solution. About 99% of the time, it is unnecessary. A little thought and the use of optional parameters to an SP is the better way.

Arthur


On Fri, Aug 29, 2014 at 9:02 AM, Jim Dettman <jimdettman at verizon.net> wrote:

> Don,
>
>   Just to add a bit to my post from last night as I couldn't see this 
> original post, you've got to be careful where you use Domain functions.
>
>   What they do is just wrap up a SQL Statement so you can execute SQL in
> places where you ordinarily can not.   For example, Dlookup() is "SELECT
> <x>
> FROM <y> WHERE <Z>".    So any place you can use SQL directly you should
> and
> a domain function is not appropriate.
>
>  For example, totaling a field in a sub form.   Just place a control in the
> footer and set its control source to:  =Sum(<expression>)
>
>  One place where domain functions are really a no-no is inside of a query.
> They are totally un-optimizable by the query processor and you are 
> guaranteeing yourself poor performance for anything over a couple of 
> hundred records.
>
>  Alternatives are executing SQL in code, performing operations on a 
> record set directly, etc.
>
>  Domain functions are handy to use, but in general, you'll find that 
> you don't use them often because there are other ways to do things.
>
> Jim.
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of 
> McGillivray, Don
> Sent: Thursday, August 28, 2014 06:28 PM
> To: accessD at databaseadvisors.com
> Subject: [AccessD] Alternatives to domain aggregate functions
>
> Hi Listers,
>
> I have a form in an Access application (users have the Access 2010 
> runtime only, on Win 7;  Split FE/BE, with BE on network share) where 
> I need to display and continuously evaluate the cumulative count and 
> value of items and assign an incrementing serial number to child 
> records as they are entered.  At this point, the form uses domain 
> aggregate functions to determine the count and sum of the 
> transactions, and the max plus 1 for the next serial number.  At 
> modest volumes (<=200 records) performance is acceptable.  Beyond 
> that, performance becomes increasingly degraded, to the point of being almost unusable by the time 400 records have been entered.
>
> Obviously, the domain aggregate approach is not working for this 
> situation, so I'm looking for more efficient approaches to fulfill the 
> aggregating/incrementing requirements.  Can anybody point me in a 
> better direction?
>
> Thanks!
>
> Don McGillivray
>
> ----------------------------------------------------------------------
> ----- For those interested in further detail, please read on . . .
>
> The application records customer payment data.  Ultimately, the 
> payment data collected by the system will be imported into an Oracle 
> database.  The payments, each consisting of a header record and one or 
> more GL distribution records, are entered in batches that correspond 
> to daily bank deposits.
> The
> payment header record contains the payment date, check number, and 
> amount, and the GL distribution record contains line item detail 
> including an application number and the GL account to which the 
> revenue is booked.  Data entry begins with the creation of a batch 
> (deposit) header record that includes the date, number of payments, 
> number of applications paid for, and total deposit amount.  (The item count and amount are used as "target"
> values during data entry to ensure that everything balances in the 
> end.) Once the batch header record is complete, the payment records 
> are entered one at a time, along with their GL details.  So I have a 
> simple hierarchy of data entities: Deposit !
>  Header - Payment Header - Payment Details, and the entry form is 
> designed (main form, sub-form, sub-form) to accommodate this 
> structure.  That's the quick and dirty description of the basic setup.
>
> A further wrinkle is that each payment record (child of the top level) 
> is associated to one or more stamp numbers that are affixed to the 
> check upon receipt, and those numbers must be included in the 
> distribution records (grandchildren to the top level) for each 
> payment.  The stamp numbers are composed of a date string (YYMMDD) 
> followed by an incrementing serial number from 1 to n each day, 
> according to the number of applications being paid for.  So, based on 
> the application count of the batch header, a list of stamp numbers can 
> be generated for each batch, and, assuming the checks are entered in 
> stamp number order, the next available number may be assigned 
> automatically to each payment until all are used up.  The entry form 
> allows the user to select from a combo box any valid stamp number for 
> any payment if necessary, but the typical scenario is to allow the 
> system to assign the numbers in sequence to the distribution records automatically.
>
> To help ensure accurate data entry, the user is required to have 
> entered values that agree with the target values.  For example, on a 
> given payment, before a new payment may be entered, the value of the 
> distribution records must equal the check amount as entered in the 
> payment header.  Similarly, the batch itself may not be posted until 
> the sum of its payment records equals the previously entered batch 
> totals (item count and amount.)  These rules are enforced by the form 
> by comparing the batch and payment header entries to the sums of the line items as data is entered.
>
> The application has been in production since May, and has functioned 
> well as designed.  However, this week an unusually large volume of 
> payments (>600) arrived on a single day, and as the batch entry 
> progressed beyond about 300 records, the form's performance became 
> increasingly degraded, until it was essentially unusable.  The 
> degradation is probably due to the methods I've employed to determine 
> the next available stamp number, compounded by the tabulation of the 
> item count and cumulative total for the batch as data entry 
> progresses.  In both cases, I'm using domain aggregate functions to 
> return the count and sum of payments entered, along with the max plus 
> 1 for the next available stamp number.  As the number of records in 
> the batch grows, these calculations take longer and longer.  The 
> effect was observed during development, leading me to modify the table 
> structure so that new records land in temporary tables before being 
> posted by the user to the permanent ones.  This im!
>  proved things quite a bit by avoiding the impact of aggregating over 
> a table whose content continues to grow over time, but apparently that 
> move is not enough when the batch volume rises beyond a certain point.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 13:09:04 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 19:09:04 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+e0+tZH14RGyqPxFyQ2gZF5jradqvWYqZEOoSxmEBE+-g@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAB0q2OsZc1FDs+OPWzaMrugBAAAAAA==@blueyonder.co.uk>
	<CA++Sg+e0+tZH14RGyqPxFyQ2gZF5jradqvWYqZEOoSxmEBE+-g@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAKUpnjdXhZ1FhBz8nKf+xzQBAAAAAA==@blueyonder.co.uk>

Agreed that you would not need to be tracking species -
Accepting that for your purposes the animal entry is the primary data record 

I was using species as an example of a grouping (parent) level for a collection
of animals
Have a google for database cascade delete 
Basically the concept is that you define a set of primary tables with 'higher
level', or generic  entries that, under referential integrity  will be defining
conditions or classes, and then you enter in a child table the detailed data
that describes a specific thing that is associated with the entries in the
earlier defined tables

Perhaps more relative to your setup
You have a row in a table detailing an animal

Then you create a table of vets and enter into that the vets associated with the
establishment (credentials checked etc.) and then you enter that:
the vet (foreign key) 
did procedure (description) 
on animal (foreign key) 
on date and will be 
billing the agreed cost 
under workorder reference ___

The accounts dept will have additional details for that vet -
Local Address
Contact Phone
Office address
Office Phone
Bank account
Invoices paid
Due
Billed
Paid
Total business 
VAT
Payment terms used
Etc.

And when the invoice comes in it is entered under a bills table with
vet(foreignkey) workorder (foreignkey) for action on date(foreignkey) to animal
(foreignkey)

So there are checks that the billing is from authorised people for agreed work
done on known dates  on specific animals 

So you can get  reports on - a vet's billing, animals treated, dates attended
etc...
 
(And - as an aside - 
Note - nothing in the database related to comments on the work that could be
considered defamatory as a court search order would find them, but postit notes
- fell in the bin when the glue dried.)

BUT

Remember earlier I indicated that I believe that rather than being strictly
normalised, the structure is up to you and should be appropriate to the forms
and reports you want.

And - I would say actually avoid cascade delete because of the danger of losing
whole blocks of data because of 1 inadvertent deletion. 


JimB

 

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 6:39 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

But you're talking in broader terms. In this database, I'd not be tracking
species without the animals. I would have no reason whatsoever to track
species.

I'm listening because you make sense -- but I'm not certain what you've
said actually applies to what I'm doing. The animals are the parent table
-- everything in the database applies to an individual animal.

Susan H.

> JimB
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com
> > wrote:
>
> > A foreign key is a key that points to the PK in another table.  You're
> > mixing keys with parent child relationships, which are defined through
> > keys.  In a data warehouse, you put a bunch of keys in the central table,
> > but in a regular database you put the parent PK into the child tables so
> > they know their mommy,  The idea is to put the keys where they are
> needed.
> >
> > Charlotte
> >



From fuller.artful at gmail.com  Fri Aug 29 13:14:01 2014
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 29 Aug 2014 14:14:01 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
Message-ID: <CAEPJO1gM+TzADBWhG4SsVmK6zjyM__xzM8m9Szb0ET=JB+3-qg@mail.gmail.com>

How can one single animal derive from two cities? If you can explain that,
then perhaps we need a M2M relationship table; but so far I do not see the
need, As far as I know, you are born in one place at one time, and that is
that.Of course, modern science being what it is, I could be way beyond the
historical picture.


On Fri, Aug 29, 2014 at 1:53 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> What I'm struggling with today is acquisitions. There are three ways that
> we acquire an animal -- live birth here at the center, from an institution,
> or through law enforcement confiscation (almost never happens, but I'm
> allowing for the possibility). So, each animal has an acquisition type, but
> depending on the type the subsequent data will be different. For example,
> if a live birth here at the center, we will also track the dam and sire
> ids. If we acquire an animal from an institution, we'll track the
> institution's info, like name, address, phone, and a contact.
>
> So, an animal has an acquisition id by type. It's easy to keep an
> institution and live birth table -- that's no problem. But how do I relate
> them back to the individual since it can come from two different tables? I
> think this is probably easier than I'm making it.
>
> Susan H.
>
>
> On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > Right now, most of my foreign keys in the parent table are simple
> lookups.
> > For instance, species -- each individual has a species and those are in a
> > child table. We'll update that table infrequently -- only if we add a new
> > species. We have several individuals of each species. Another is gender
> --
> > female and male, but the parent table has a foreign key to the gender
> > table. (Gender's probably overkill, but I'm on autopilot I think). I'm
> also
> > tracking acquisition method -- there are only three, so again, it's a
> > lookup table and not a true child table.
> >
> > Susan H.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > charlotte.foust at gmail.com> wrote:
> >
> >> A foreign key is a key that points to the PK in another table.  You're
> >> mixing keys with parent child relationships, which are defined through
> >> keys.  In a data warehouse, you put a bunch of keys in the central
> table,
> >> but in a regular database you put the parent PK into the child tables so
> >> they know their mommy,  The idea is to put the keys where they are
> needed.
> >>
> >> Charlotte
> >>
> >>
> >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> >> wrote:
> >>
> >> > I'll spend the morning rereading the book Martin and I wrote, brushing
> >> up
> >> > on the normalization part. I've forgotten a lot of the basics. I'm
> >> writing
> >> > an animal tracing database in Access and I'm trying to remember if it
> >> > matters where the fk goes. Now, I remember its purpose and all that,
> >> but it
> >> > would be so much simpler if I could just drop them all into the main
> >> table
> >> > instead of adding a fk to all the child tables to the main table -- I
> >> think
> >> > anyway.
> >> >
> >> > So, I've got a main table of animals and all of the remaining tables
> are
> >> > child tables of a sort and a few lookup tables. Is it reasonable to
> just
> >> > add a fk to all those child tables in my parent table?
> >> >
> >> > I just don't remember. I haven't built a database in... seriously...
> 10
> >> > years? It's been long enough that I'm really struggling.
> >> >
> >> > Susan H.
> >> > --
> >> > AccessD mailing list
> >> > AccessD at databaseadvisors.com
> >> > http://databaseadvisors.com/mailman/listinfo/accessd
> >> > Website: http://www.databaseadvisors.com
> >> >
> >> --
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> http://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> >
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur

From df.waters at outlook.com  Fri Aug 29 13:18:28 2014
From: df.waters at outlook.com (Dan Waters)
Date: Fri, 29 Aug 2014 13:18:28 -0500
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
Message-ID: <BLU176-DS184C87818B769EAC20DFB6F6DB0@phx.gbl>

Hi Susan,

I know I'm jumping into this after a lot of discussion has already occurred.


You might consider having a single table for each animal with all its
one-time information.

I would treat this as a business process that has a beginning, middle
stages, and an end.  The tblAnimalMain table would carry the information for
each animal that would be recorded only once, like acquisition, animal
characteristics, current storage location, final disposition, etc.
tblAnimalMain would be your top-level table.

Because each animal is acquired in one and only one way, you could put the
acquisition information into the tblAnimalMain table.  Not all fields in
tblAnimalMain would be used for every animal.

I would be thinking of one-many tables like tblExamPlusResult (with another
one-many table for specific tests that were run and the result of each, for
each exam).  You'll also want to keep track of treatments/surgeries and the
results of those (could be another one-many).

Hope this is helpful,
Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 12:54 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

What I'm struggling with today is acquisitions. There are three ways that we
acquire an animal -- live birth here at the center, from an institution, or
through law enforcement confiscation (almost never happens, but I'm allowing
for the possibility). So, each animal has an acquisition type, but depending
on the type the subsequent data will be different. For example, if a live
birth here at the center, we will also track the dam and sire ids. If we
acquire an animal from an institution, we'll track the institution's info,
like name, address, phone, and a contact.

So, an animal has an acquisition id by type. It's easy to keep an
institution and live birth table -- that's no problem. But how do I relate
them back to the individual since it can come from two different tables? I
think this is probably easier than I'm making it.

Susan H.


On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are 
> in a child table. We'll update that table infrequently -- only if we 
> add a new species. We have several individuals of each species. 
> Another is gender -- female and male, but the parent table has a 
> foreign key to the gender table. (Gender's probably overkill, but I'm 
> on autopilot I think). I'm also tracking acquisition method -- there 
> are only three, so again, it's a lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust < 
> charlotte.foust at gmail.com> wrote:
>
>> A foreign key is a key that points to the PK in another table.  
>> You're mixing keys with parent child relationships, which are defined 
>> through keys.  In a data warehouse, you put a bunch of keys in the 
>> central table, but in a regular database you put the parent PK into 
>> the child tables so they know their mommy,  The idea is to put the keys
where they are needed.
>>
>> Charlotte
>>
>>
>> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
>> wrote:
>>
>> > I'll spend the morning rereading the book Martin and I wrote, 
>> > brushing
>> up
>> > on the normalization part. I've forgotten a lot of the basics. I'm
>> writing
>> > an animal tracing database in Access and I'm trying to remember if 
>> > it matters where the fk goes. Now, I remember its purpose and all 
>> > that,
>> but it
>> > would be so much simpler if I could just drop them all into the 
>> > main
>> table
>> > instead of adding a fk to all the child tables to the main table -- 
>> > I
>> think
>> > anyway.
>> >
>> > So, I've got a main table of animals and all of the remaining 
>> > tables are child tables of a sort and a few lookup tables. Is it 
>> > reasonable to just add a fk to all those child tables in my parent
table?
>> >
>> > I just don't remember. I haven't built a database in... 
>> > seriously... 10 years? It's been long enough that I'm really
struggling.
>> >
>> > Susan H.
>> > --
>> > AccessD mailing list
>> > AccessD at databaseadvisors.com
>> > http://databaseadvisors.com/mailman/listinfo/accessd
>> > Website: http://www.databaseadvisors.com
>> >
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 13:22:26 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 19:22:26 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAACkdv/jalelPhslSIEJqqzYBAAAAAA==@blueyonder.co.uk>

Decide if the data can be assembled in 1 common table with some fields not
entered, or set to specific values  "N/A" or 1/1/1900 
Or do you need different tables for the different sources ?
As in confiscated from another institution and they have the breeding records
from the institution they got it from -
 2 sets that give different information, maybe genetic modified combination of
genes with 3 parents!
(Yes - devilish view in'tnit)

Then will you have 1 or more than 1 of each of those entries for each animal?

Those entries will have a FK to point to the animal id (PK on the animal table) 
You then have to decide if there is to only be 1 of each kind of entry than you
can have foreign keys in the primary Animal id record so they can be selected on
the basis of the fk existing, or not
Or if you will need to include a SQL (whatever) search for entries in those
notes tables that are associated with the Animil id entry

So you can have keys in each level pointing to the other entry, or just have all
with the PK of the animal record and go looking for them 



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 6:54 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

What I'm struggling with today is acquisitions. There are three ways that
we acquire an animal -- live birth here at the center, from an institution,
or through law enforcement confiscation (almost never happens, but I'm
allowing for the possibility). So, each animal has an acquisition type, but
depending on the type the subsequent data will be different. For example,
if a live birth here at the center, we will also track the dam and sire
ids. If we acquire an animal from an institution, we'll track the
institution's info, like name, address, phone, and a contact.

So, an animal has an acquisition id by type. It's easy to keep an
institution and live birth table -- that's no problem. But how do I relate
them back to the individual since it can come from two different tables? I
think this is probably easier than I'm making it.

Susan H.


On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are in a
> child table. We'll update that table infrequently -- only if we add a new
> species. We have several individuals of each species. Another is gender --
> female and male, but the parent table has a foreign key to the gender
> table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
> tracking acquisition method -- there are only three, so again, it's a
> lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com> wrote:
>
>> A foreign key is a key that points to the PK in another table.  You're
>> mixing keys with parent child relationships, which are defined through
>> keys.  In a data warehouse, you put a bunch of keys in the central table,
>> but in a regular database you put the parent PK into the child tables so
>> they know their mommy,  The idea is to put the keys where they are needed.
>>
>> Charlotte
>>
>>
>> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
>> wrote:
>>
>> > I'll spend the morning rereading the book Martin and I wrote, brushing
>> up
>> > on the normalization part. I've forgotten a lot of the basics. I'm
>> writing
>> > an animal tracing database in Access and I'm trying to remember if it
>> > matters where the fk goes. Now, I remember its purpose and all that,
>> but it
>> > would be so much simpler if I could just drop them all into the main
>> table
>> > instead of adding a fk to all the child tables to the main table -- I
>> think
>> > anyway.
>> >
>> > So, I've got a main table of animals and all of the remaining tables are
>> > child tables of a sort and a few lookup tables. Is it reasonable to just
>> > add a fk to all those child tables in my parent table?
>> >
>> > I just don't remember. I haven't built a database in... seriously... 10
>> > years? It's been long enough that I'm really struggling.
>> >
>> > Susan H.
>> > --
>> > AccessD mailing list
>> > AccessD at databaseadvisors.com
>> > http://databaseadvisors.com/mailman/listinfo/accessd
>> > Website: http://www.databaseadvisors.com
>> >
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From dnod at aol.com  Fri Aug 29 13:23:41 2014
From: dnod at aol.com (Dean Davids)
Date: Fri, 29 Aug 2014 14:23:41 -0400
Subject: [AccessD] Query Help
Message-ID: <04F64020-4C27-40E8-8B02-E852F989F429@aol.com>

I am sure this is purely my ignorance for having not cracked open an Access db in some years. What seemed to be a simple query in my head has me chasing my tail.

>From qbd Grid:
SELECT tbleProjects.ProjectID, tbleProjects.ProjectName, Max(tblContracts.ContractAmount) AS MaxOfContractAmount, tblClients.CompanyName
FROM tbleProjects INNER JOIN (tblClients RIGHT JOIN tblContracts ON tblClients.ClientID = tblContracts.ContractClientID) ON tbleProjects.ProjectID = tblContracts.CotractProjectID
GROUP BY tbleProjects.ProjectID, tbleProjects.ProjectName, tblClients.CompanyName
ORDER BY tbleProjects.ProjectName;

tbleProjects is one to many tblContracts.
tblClients is one to many tblContracts.
I am trying to get the client of the highest value contract associated as the main client of the project in a query.

With the above statement, I get duplicates for each project that has multiple contracts.
If I leave out tblClients, I get no dupes and I get the max contract amount, which I need, but I also need the Client. Alternatively I'd take the PK from the max contract which I can then use to retrieve the client.

Am I going about this wrong?

Thank in advance for suggestions,

Dean S. Davids
Fort Lauderdale, FL


From ssharkins at gmail.com  Fri Aug 29 13:36:57 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 14:36:57 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CAEPJO1gM+TzADBWhG4SsVmK6zjyM__xzM8m9Szb0ET=JB+3-qg@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
	<CAEPJO1gM+TzADBWhG4SsVmK6zjyM__xzM8m9Szb0ET=JB+3-qg@mail.gmail.com>
Message-ID: <CA++Sg+dps3HCEVbWdrRo_DhUxeZ3if9UcqdN1BWAeyV1-HkWYA@mail.gmail.com>

No, it can't. It can derive from here, by actual birth at our center. Or,
we can acquire it from another institution. When an animal is born here, we
will know its parents. When we acquire it from another institution, we
won't. I'm just identifying how we acquired the animal -- where it came
from, how it came to be here.

So, at this point, what I have follows:

A table of individual animals identifying them by the name they go by here,
species, and a few other fields. I'm also identifying each animal with an
acquisition type.

I have an acquisitionbirth table that includes the individual as a foreign
key. I'll include the dam and sire ids as well.
I have an acqsitioninstitution table that includes the individual and
institution as a foreign key. There is a second table for institution
information -- address, phone, and all that.

This seems to make sense to me -- but I haven't tried to work with it yet.
I'm not sure the acquisition type is actually needed -- but I need someway
for the users to id the acquisition, so the app knows what forms to supply
for data entry purposes.

Susan H.


On Fri, Aug 29, 2014 at 2:14 PM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> How can one single animal derive from two cities? If you can explain that,
> then perhaps we need a M2M relationship table; but so far I do not see the
> need, As far as I know, you are born in one place at one time, and that is
> that.Of course, modern science being what it is, I could be way beyond the
> historical picture.
>
>
> On Fri, Aug 29, 2014 at 1:53 PM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > What I'm struggling with today is acquisitions. There are three ways that
> > we acquire an animal -- live birth here at the center, from an
> institution,
> > or through law enforcement confiscation (almost never happens, but I'm
> > allowing for the possibility). So, each animal has an acquisition type,
> but
> > depending on the type the subsequent data will be different. For example,
> > if a live birth here at the center, we will also track the dam and sire
> > ids. If we acquire an animal from an institution, we'll track the
> > institution's info, like name, address, phone, and a contact.
> >
> > So, an animal has an acquisition id by type. It's easy to keep an
> > institution and live birth table -- that's no problem. But how do I
> relate
> > them back to the individual since it can come from two different tables?
> I
> > think this is probably easier than I'm making it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> > wrote:
> >
> > > Right now, most of my foreign keys in the parent table are simple
> > lookups.
> > > For instance, species -- each individual has a species and those are
> in a
> > > child table. We'll update that table infrequently -- only if we add a
> new
> > > species. We have several individuals of each species. Another is gender
> > --
> > > female and male, but the parent table has a foreign key to the gender
> > > table. (Gender's probably overkill, but I'm on autopilot I think). I'm
> > also
> > > tracking acquisition method -- there are only three, so again, it's a
> > > lookup table and not a true child table.
> > >
> > > Susan H.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > charlotte.foust at gmail.com> wrote:
> > >
> > >> A foreign key is a key that points to the PK in another table.  You're
> > >> mixing keys with parent child relationships, which are defined through
> > >> keys.  In a data warehouse, you put a bunch of keys in the central
> > table,
> > >> but in a regular database you put the parent PK into the child tables
> so
> > >> they know their mommy,  The idea is to put the keys where they are
> > needed.
> > >>
> > >> Charlotte
> > >>
> > >>
> > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> > >> wrote:
> > >>
> > >> > I'll spend the morning rereading the book Martin and I wrote,
> brushing
> > >> up
> > >> > on the normalization part. I've forgotten a lot of the basics. I'm
> > >> writing
> > >> > an animal tracing database in Access and I'm trying to remember if
> it
> > >> > matters where the fk goes. Now, I remember its purpose and all that,
> > >> but it
> > >> > would be so much simpler if I could just drop them all into the main
> > >> table
> > >> > instead of adding a fk to all the child tables to the main table --
> I
> > >> think
> > >> > anyway.
> > >> >
> > >> > So, I've got a main table of animals and all of the remaining tables
> > are
> > >> > child tables of a sort and a few lookup tables. Is it reasonable to
> > just
> > >> > add a fk to all those child tables in my parent table?
> > >> >
> > >> > I just don't remember. I haven't built a database in... seriously...
> > 10
> > >> > years? It's been long enough that I'm really struggling.
> > >> >
> > >> > Susan H.
> > >> > --
> > >> > AccessD mailing list
> > >> > AccessD at databaseadvisors.com
> > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > >> > Website: http://www.databaseadvisors.com
> > >> >
> > >> --
> > >> AccessD mailing list
> > >> AccessD at databaseadvisors.com
> > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > >> Website: http://www.databaseadvisors.com
> > >>
> > >
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From ssharkins at gmail.com  Fri Aug 29 13:41:55 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 14:41:55 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <BLU176-DS184C87818B769EAC20DFB6F6DB0@phx.gbl>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
	<BLU176-DS184C87818B769EAC20DFB6F6DB0@phx.gbl>
Message-ID: <CA++Sg+ff0Oec9eGgaPVDv8PuCTqZCPYuL0RW=KG8K38D-Qy-wQ@mail.gmail.com>

Dan, that's a good description of what I'm trying to do -- at this point,
the individual animals are driving everything and I do have that main table
and each individual does have a few attributes.

We'll eventually add all kinds of activity -- health, diet, enrichment,
safety protocols, but right now, we'd just like to get the animals entered!
:)

You know, I used to have all these rules memorized -- I felt like I could
do this stuff in my sleep, but now... after all this time, I am truly
feeling... like an idiot. :) I'm glad you guys are still around!

Susan H.


On Fri, Aug 29, 2014 at 2:18 PM, Dan Waters <df.waters at outlook.com> wrote:

> Hi Susan,
>
> I know I'm jumping into this after a lot of discussion has already
> occurred.
>
>
> You might consider having a single table for each animal with all its
> one-time information.
>
> I would treat this as a business process that has a beginning, middle
> stages, and an end.  The tblAnimalMain table would carry the information
> for
> each animal that would be recorded only once, like acquisition, animal
> characteristics, current storage location, final disposition, etc.
> tblAnimalMain would be your top-level table.
>
> Because each animal is acquired in one and only one way, you could put the
> acquisition information into the tblAnimalMain table.  Not all fields in
> tblAnimalMain would be used for every animal.
>
> I would be thinking of one-many tables like tblExamPlusResult (with another
> one-many table for specific tests that were run and the result of each, for
> each exam).  You'll also want to keep track of treatments/surgeries and the
> results of those (could be another one-many).
>
> Hope this is helpful,
> Dan
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 12:54 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Normalization discussion
>
> What I'm struggling with today is acquisitions. There are three ways that
> we
> acquire an animal -- live birth here at the center, from an institution, or
> through law enforcement confiscation (almost never happens, but I'm
> allowing
> for the possibility). So, each animal has an acquisition type, but
> depending
> on the type the subsequent data will be different. For example, if a live
> birth here at the center, we will also track the dam and sire ids. If we
> acquire an animal from an institution, we'll track the institution's info,
> like name, address, phone, and a contact.
>
> So, an animal has an acquisition id by type. It's easy to keep an
> institution and live birth table -- that's no problem. But how do I relate
> them back to the individual since it can come from two different tables? I
> think this is probably easier than I'm making it.
>
> Susan H.
>
>
> On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > Right now, most of my foreign keys in the parent table are simple
> lookups.
> > For instance, species -- each individual has a species and those are
> > in a child table. We'll update that table infrequently -- only if we
> > add a new species. We have several individuals of each species.
> > Another is gender -- female and male, but the parent table has a
> > foreign key to the gender table. (Gender's probably overkill, but I'm
> > on autopilot I think). I'm also tracking acquisition method -- there
> > are only three, so again, it's a lookup table and not a true child table.
> >
> > Susan H.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > charlotte.foust at gmail.com> wrote:
> >
> >> A foreign key is a key that points to the PK in another table.
> >> You're mixing keys with parent child relationships, which are defined
> >> through keys.  In a data warehouse, you put a bunch of keys in the
> >> central table, but in a regular database you put the parent PK into
> >> the child tables so they know their mommy,  The idea is to put the keys
> where they are needed.
> >>
> >> Charlotte
> >>
> >>
> >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> >> wrote:
> >>
> >> > I'll spend the morning rereading the book Martin and I wrote,
> >> > brushing
> >> up
> >> > on the normalization part. I've forgotten a lot of the basics. I'm
> >> writing
> >> > an animal tracing database in Access and I'm trying to remember if
> >> > it matters where the fk goes. Now, I remember its purpose and all
> >> > that,
> >> but it
> >> > would be so much simpler if I could just drop them all into the
> >> > main
> >> table
> >> > instead of adding a fk to all the child tables to the main table --
> >> > I
> >> think
> >> > anyway.
> >> >
> >> > So, I've got a main table of animals and all of the remaining
> >> > tables are child tables of a sort and a few lookup tables. Is it
> >> > reasonable to just add a fk to all those child tables in my parent
> table?
> >> >
> >> > I just don't remember. I haven't built a database in...
> >> > seriously... 10 years? It's been long enough that I'm really
> struggling.
> >> >
> >> > Susan H.
> >> > --
> >> > AccessD mailing list
> >> > AccessD at databaseadvisors.com
> >> > http://databaseadvisors.com/mailman/listinfo/accessd
> >> > Website: http://www.databaseadvisors.com
> >> >
> >> --
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> http://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> >
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From rockysmolin at bchacc.com  Fri Aug 29 13:42:51 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 29 Aug 2014 11:42:51 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com><CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com><CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
Message-ID: <2BE2A31A14D64E28B481846BC43EA207@HAL9007>

Since this is a small database used by a few people, you can make life easy
for yourself.  Put all the  fields you need for each of the three type of
acquisition into the Animal table.  I would also not bother with an
Acquisition Type table with a PK and an FK in the animal table. Just (gasp)
put the words Live Birth, Acquisition, or Law Enforcement right in the
Acquisition Type field (text).  Unnormalized?  Yes.  Simple?  Yes.  And easy
to see when you look in the back end.

In the front end if you want to get fancy, you can appear and/or disappear
the different fields you need depending on acquisition type.  Or
enable/disable. But not necessary.

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 10:54 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

What I'm struggling with today is acquisitions. There are three ways that we
acquire an animal -- live birth here at the center, from an institution, or
through law enforcement confiscation (almost never happens, but I'm allowing
for the possibility). So, each animal has an acquisition type, but depending
on the type the subsequent data will be different. For example, if a live
birth here at the center, we will also track the dam and sire ids. If we
acquire an animal from an institution, we'll track the institution's info,
like name, address, phone, and a contact.

So, an animal has an acquisition id by type. It's easy to keep an
institution and live birth table -- that's no problem. But how do I relate
them back to the individual since it can come from two different tables? I
think this is probably easier than I'm making it.

Susan H.


On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are 
> in a child table. We'll update that table infrequently -- only if we 
> add a new species. We have several individuals of each species. 
> Another is gender -- female and male, but the parent table has a 
> foreign key to the gender table. (Gender's probably overkill, but I'm 
> on autopilot I think). I'm also tracking acquisition method -- there 
> are only three, so again, it's a lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust < 
> charlotte.foust at gmail.com> wrote:
>
>> A foreign key is a key that points to the PK in another table.  
>> You're mixing keys with parent child relationships, which are defined 
>> through keys.  In a data warehouse, you put a bunch of keys in the 
>> central table, but in a regular database you put the parent PK into 
>> the child tables so they know their mommy,  The idea is to put the keys
where they are needed.
>>
>> Charlotte
>>
>>
>> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
>> wrote:
>>
>> > I'll spend the morning rereading the book Martin and I wrote, 
>> > brushing
>> up
>> > on the normalization part. I've forgotten a lot of the basics. I'm
>> writing
>> > an animal tracing database in Access and I'm trying to remember if 
>> > it matters where the fk goes. Now, I remember its purpose and all 
>> > that,
>> but it
>> > would be so much simpler if I could just drop them all into the 
>> > main
>> table
>> > instead of adding a fk to all the child tables to the main table -- 
>> > I
>> think
>> > anyway.
>> >
>> > So, I've got a main table of animals and all of the remaining 
>> > tables are child tables of a sort and a few lookup tables. Is it 
>> > reasonable to just add a fk to all those child tables in my parent
table?
>> >
>> > I just don't remember. I haven't built a database in... 
>> > seriously... 10 years? It's been long enough that I'm really
struggling.
>> >
>> > Susan H.
>> > --
>> > AccessD mailing list
>> > AccessD at databaseadvisors.com
>> > http://databaseadvisors.com/mailman/listinfo/accessd
>> > Website: http://www.databaseadvisors.com
>> >
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 13:51:20 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 14:51:20 -0400
Subject: [AccessD] Normalization discussion
Message-ID: <CA++Sg+fpXPH4WyEMO6Rq_z=MsvU7P=s3OZoUS10yPd-t+AJeLw@mail.gmail.com>

On Fri, Aug 29, 2014 at 2:22 PM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

> Decide if the data can be assembled in 1 common table with some fields not
> entered, or set to specific values  "N/A" or 1/1/1900
>

=========I considered that, but there would be a lot of blanks.


> Or do you need different tables for the different sources ?
>

=========This is what I've done -- but sources would be the wrong term I
think -- we acquire the animals in different ways. One ways is taking them
from other institutions.


> As in confiscated from another institution and they have the breeding
> records
> from the institution they got it from -
>

=========For our purposes, this won't matter. It'll be in filed paperwork
and available if needed, but it won't be something we'd actually need for
our reporting.


>  2 sets that give different information, maybe genetic modified
> combination of
> genes with 3 parents!
> (Yes - devilish view in'tnit)
>
Then will you have 1 or more than 1 of each of those entries for each
animal?

=========Stop it! ;)  Not happening -- everything here is a native species
from perfectly normal acquisitions. Most come from rehabbers or rescues. We
don't have exotics. Nothing fancy. :)

Susan H.

From ssharkins at gmail.com  Fri Aug 29 13:52:17 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 14:52:17 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <2BE2A31A14D64E28B481846BC43EA207@HAL9007>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>
	<2BE2A31A14D64E28B481846BC43EA207@HAL9007>
Message-ID: <CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>

Seriously? I would love to do it this way -- nobody but me will ever work
on it.

Susan H.


On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> Since this is a small database used by a few people, you can make life easy
> for yourself.  Put all the  fields you need for each of the three type of
> acquisition into the Animal table.  I would also not bother with an
> Acquisition Type table with a PK and an FK in the animal table. Just (gasp)
> put the words Live Birth, Acquisition, or Law Enforcement right in the
> Acquisition Type field (text).  Unnormalized?  Yes.  Simple?  Yes.  And
> easy
> to see when you look in the back end.
>
> In the front end if you want to get fancy, you can appear and/or disappear
> the different fields you need depending on acquisition type.  Or
> enable/disable. But not necessary.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 10:54 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Normalization discussion
>
> What I'm struggling with today is acquisitions. There are three ways that
> we
> acquire an animal -- live birth here at the center, from an institution, or
> through law enforcement confiscation (almost never happens, but I'm
> allowing
> for the possibility). So, each animal has an acquisition type, but
> depending
> on the type the subsequent data will be different. For example, if a live
> birth here at the center, we will also track the dam and sire ids. If we
> acquire an animal from an institution, we'll track the institution's info,
> like name, address, phone, and a contact.
>
> So, an animal has an acquisition id by type. It's easy to keep an
> institution and live birth table -- that's no problem. But how do I relate
> them back to the individual since it can come from two different tables? I
> think this is probably easier than I'm making it.
>
> Susan H.
>
>
> On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > Right now, most of my foreign keys in the parent table are simple
> lookups.
> > For instance, species -- each individual has a species and those are
> > in a child table. We'll update that table infrequently -- only if we
> > add a new species. We have several individuals of each species.
> > Another is gender -- female and male, but the parent table has a
> > foreign key to the gender table. (Gender's probably overkill, but I'm
> > on autopilot I think). I'm also tracking acquisition method -- there
> > are only three, so again, it's a lookup table and not a true child table.
> >
> > Susan H.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > charlotte.foust at gmail.com> wrote:
> >
> >> A foreign key is a key that points to the PK in another table.
> >> You're mixing keys with parent child relationships, which are defined
> >> through keys.  In a data warehouse, you put a bunch of keys in the
> >> central table, but in a regular database you put the parent PK into
> >> the child tables so they know their mommy,  The idea is to put the keys
> where they are needed.
> >>
> >> Charlotte
> >>
> >>
> >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> >> wrote:
> >>
> >> > I'll spend the morning rereading the book Martin and I wrote,
> >> > brushing
> >> up
> >> > on the normalization part. I've forgotten a lot of the basics. I'm
> >> writing
> >> > an animal tracing database in Access and I'm trying to remember if
> >> > it matters where the fk goes. Now, I remember its purpose and all
> >> > that,
> >> but it
> >> > would be so much simpler if I could just drop them all into the
> >> > main
> >> table
> >> > instead of adding a fk to all the child tables to the main table --
> >> > I
> >> think
> >> > anyway.
> >> >
> >> > So, I've got a main table of animals and all of the remaining
> >> > tables are child tables of a sort and a few lookup tables. Is it
> >> > reasonable to just add a fk to all those child tables in my parent
> table?
> >> >
> >> > I just don't remember. I haven't built a database in...
> >> > seriously... 10 years? It's been long enough that I'm really
> struggling.
> >> >
> >> > Susan H.
> >> > --
> >> > AccessD mailing list
> >> > AccessD at databaseadvisors.com
> >> > http://databaseadvisors.com/mailman/listinfo/accessd
> >> > Website: http://www.databaseadvisors.com
> >> >
> >> --
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> http://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> >
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From rockysmolin at bchacc.com  Fri Aug 29 14:02:18 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 29 Aug 2014 12:02:18 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com><CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com><CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com><CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com><2BE2A31A14D64E28B481846BC43EA207@HAL9007>
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>
Message-ID: <517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>

I always engineer my dbs for the constraints of the application and to make
the user happy.  I do things the easy way - for me.  Normalization is great
when you're talking 100k rows.  Makes the app respond fast.  But I try not
to over engineer my apps.

"A good program is one that works."

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 11:52 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

Seriously? I would love to do it this way -- nobody but me will ever work on
it.

Susan H.


On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> Since this is a small database used by a few people, you can make life 
> easy for yourself.  Put all the  fields you need for each of the three 
> type of acquisition into the Animal table.  I would also not bother 
> with an Acquisition Type table with a PK and an FK in the animal 
> table. Just (gasp) put the words Live Birth, Acquisition, or Law 
> Enforcement right in the Acquisition Type field (text).  Unnormalized?  
> Yes.  Simple?  Yes.  And easy to see when you look in the back end.
>
> In the front end if you want to get fancy, you can appear and/or 
> disappear the different fields you need depending on acquisition type.  
> Or enable/disable. But not necessary.
>
> R
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan 
> Harkins
> Sent: Friday, August 29, 2014 10:54 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Normalization discussion
>
> What I'm struggling with today is acquisitions. There are three ways 
> that we acquire an animal -- live birth here at the center, from an 
> institution, or through law enforcement confiscation (almost never 
> happens, but I'm allowing for the possibility). So, each animal has an 
> acquisition type, but depending on the type the subsequent data will 
> be different. For example, if a live birth here at the center, we will 
> also track the dam and sire ids. If we acquire an animal from an 
> institution, we'll track the institution's info, like name, address, 
> phone, and a contact.
>
> So, an animal has an acquisition id by type. It's easy to keep an 
> institution and live birth table -- that's no problem. But how do I 
> relate them back to the individual since it can come from two 
> different tables? I think this is probably easier than I'm making it.
>
> Susan H.
>
>
> On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > Right now, most of my foreign keys in the parent table are simple
> lookups.
> > For instance, species -- each individual has a species and those are 
> > in a child table. We'll update that table infrequently -- only if we 
> > add a new species. We have several individuals of each species.
> > Another is gender -- female and male, but the parent table has a 
> > foreign key to the gender table. (Gender's probably overkill, but 
> > I'm on autopilot I think). I'm also tracking acquisition method -- 
> > there are only three, so again, it's a lookup table and not a true child
table.
> >
> > Susan H.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust < 
> > charlotte.foust at gmail.com> wrote:
> >
> >> A foreign key is a key that points to the PK in another table.
> >> You're mixing keys with parent child relationships, which are 
> >> defined through keys.  In a data warehouse, you put a bunch of keys 
> >> in the central table, but in a regular database you put the parent 
> >> PK into the child tables so they know their mommy,  The idea is to 
> >> put the keys
> where they are needed.
> >>
> >> Charlotte
> >>
> >>
> >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins 
> >> <ssharkins at gmail.com>
> >> wrote:
> >>
> >> > I'll spend the morning rereading the book Martin and I wrote, 
> >> > brushing
> >> up
> >> > on the normalization part. I've forgotten a lot of the basics. 
> >> > I'm
> >> writing
> >> > an animal tracing database in Access and I'm trying to remember 
> >> > if it matters where the fk goes. Now, I remember its purpose and 
> >> > all that,
> >> but it
> >> > would be so much simpler if I could just drop them all into the 
> >> > main
> >> table
> >> > instead of adding a fk to all the child tables to the main table 
> >> > -- I
> >> think
> >> > anyway.
> >> >
> >> > So, I've got a main table of animals and all of the remaining 
> >> > tables are child tables of a sort and a few lookup tables. Is it 
> >> > reasonable to just add a fk to all those child tables in my 
> >> > parent
> table?
> >> >
> >> > I just don't remember. I haven't built a database in...
> >> > seriously... 10 years? It's been long enough that I'm really
> struggling.
> >> >
> >> > Susan H.
> >> > --
> >> > AccessD mailing list
> >> > AccessD at databaseadvisors.com
> >> > http://databaseadvisors.com/mailman/listinfo/accessd
> >> > Website: http://www.databaseadvisors.com
> >> >
> >> --
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> http://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> >
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 14:04:08 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 20:04:08 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+dps3HCEVbWdrRo_DhUxeZ3if9UcqdN1BWAeyV1-HkWYA@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>	<CA++Sg+fO6i_Q+vLUjnuzcEkUWzyth7U8dvHCaZFMrACgWOPnoQ@mail.gmail.com>	<CAEPJO1gM+TzADBWhG4SsVmK6zjyM__xzM8m9Szb0ET=JB+3-qg@mail.gmail.com>
	<CA++Sg+dps3HCEVbWdrRo_DhUxeZ3if9UcqdN1BWAeyV1-HkWYA@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAC9oMgNtwdxOmbkKvkKmKw4BAAAAAA==@blueyonder.co.uk>

And I would include a searchable comments field on many of the entries so you
can include a short set of notes - such as a "See documents in folder ___" 
Also consider that many of the 'acquired from' places will probably not exist,
or have moved shortly after you get the animals from them - otherwise why would
they not keep the animals

Also - 'Technically' within the database you will identify the animal by the
primary key of the entry in the 'Animal table'
The rest of the detail - called by name, got from, are associated entries that
may be in the Animal record or in an associated table as identified by:
An entry in the Animal record giving the key to that other entry  
That entry having a FK that identifies the Animal record key (maybe more than 1
such entry as in vet attention)
Possibly a marker in the Animal record to indicate that there are entries in the
table associated with the marker 
Or even a count of those associated entries 

How you link the data is up to you - but again, consider how you are going to
have the system generate reports and forms.

And - will you be getting offspring from them - that will lead into a whole new
concept of hierarchical entries for descendents of descendents of ...

Think of the entries if you're breeding mice - or spiders!

JimB


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 7:37 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

No, it can't. It can derive from here, by actual birth at our center. Or,
we can acquire it from another institution. When an animal is born here, we
will know its parents. When we acquire it from another institution, we
won't. I'm just identifying how we acquired the animal -- where it came
from, how it came to be here.

So, at this point, what I have follows:

A table of individual animals identifying them by the name they go by here,
species, and a few other fields. I'm also identifying each animal with an
acquisition type.

I have an acquisitionbirth table that includes the individual as a foreign
key. I'll include the dam and sire ids as well.
I have an acqsitioninstitution table that includes the individual and
institution as a foreign key. There is a second table for institution
information -- address, phone, and all that.

This seems to make sense to me -- but I haven't tried to work with it yet.
I'm not sure the acquisition type is actually needed -- but I need someway
for the users to id the acquisition, so the app knows what forms to supply
for data entry purposes.

Susan H.


On Fri, Aug 29, 2014 at 2:14 PM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> How can one single animal derive from two cities? If you can explain that,
> then perhaps we need a M2M relationship table; but so far I do not see the
> need, As far as I know, you are born in one place at one time, and that is
> that.Of course, modern science being what it is, I could be way beyond the
> historical picture.
>
>
> On Fri, Aug 29, 2014 at 1:53 PM, Susan Harkins <ssharkins at gmail.com>
> wrote:
>
> > What I'm struggling with today is acquisitions. There are three ways that
> > we acquire an animal -- live birth here at the center, from an
> institution,
> > or through law enforcement confiscation (almost never happens, but I'm
> > allowing for the possibility). So, each animal has an acquisition type,
> but
> > depending on the type the subsequent data will be different. For example,
> > if a live birth here at the center, we will also track the dam and sire
> > ids. If we acquire an animal from an institution, we'll track the
> > institution's info, like name, address, phone, and a contact.
> >
> > So, an animal has an acquisition id by type. It's easy to keep an
> > institution and live birth table -- that's no problem. But how do I
> relate
> > them back to the individual since it can come from two different tables?
> I
> > think this is probably easier than I'm making it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins <ssharkins at gmail.com>
> > wrote:
> >
> > > Right now, most of my foreign keys in the parent table are simple
> > lookups.
> > > For instance, species -- each individual has a species and those are
> in a
> > > child table. We'll update that table infrequently -- only if we add a
> new
> > > species. We have several individuals of each species. Another is gender
> > --
> > > female and male, but the parent table has a foreign key to the gender
> > > table. (Gender's probably overkill, but I'm on autopilot I think). I'm
> > also
> > > tracking acquisition method -- there are only three, so again, it's a
> > > lookup table and not a true child table.
> > >
> > > Susan H.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > charlotte.foust at gmail.com> wrote:
> > >
> > >> A foreign key is a key that points to the PK in another table.  You're
> > >> mixing keys with parent child relationships, which are defined through
> > >> keys.  In a data warehouse, you put a bunch of keys in the central
> > table,
> > >> but in a regular database you put the parent PK into the child tables
> so
> > >> they know their mommy,  The idea is to put the keys where they are
> > needed.
> > >>
> > >> Charlotte
> > >>
> > >>
> > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> > >> wrote:
> > >>
> > >> > I'll spend the morning rereading the book Martin and I wrote,
> brushing
> > >> up
> > >> > on the normalization part. I've forgotten a lot of the basics. I'm
> > >> writing
> > >> > an animal tracing database in Access and I'm trying to remember if
> it
> > >> > matters where the fk goes. Now, I remember its purpose and all that,
> > >> but it
> > >> > would be so much simpler if I could just drop them all into the main
> > >> table
> > >> > instead of adding a fk to all the child tables to the main table --
> I
> > >> think
> > >> > anyway.
> > >> >
> > >> > So, I've got a main table of animals and all of the remaining tables
> > are
> > >> > child tables of a sort and a few lookup tables. Is it reasonable to
> > just
> > >> > add a fk to all those child tables in my parent table?
> > >> >
> > >> > I just don't remember. I haven't built a database in... seriously...
> > 10
> > >> > years? It's been long enough that I'm really struggling.
> > >> >
> > >> > Susan H.
> > >> > --
> > >> > AccessD mailing list
> > >> > AccessD at databaseadvisors.com
> > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > >> > Website: http://www.databaseadvisors.com
> > >> >
> > >> --
> > >> AccessD mailing list
> > >> AccessD at databaseadvisors.com
> > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > >> Website: http://www.databaseadvisors.com
> > >>
> > >
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Fri Aug 29 14:11:03 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 20:11:03 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+fpXPH4WyEMO6Rq_z=MsvU7P=s3OZoUS10yPd-t+AJeLw@mail.gmail.com>
References: <CA++Sg+fpXPH4WyEMO6Rq_z=MsvU7P=s3OZoUS10yPd-t+AJeLw@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAHCDlM7B0shLt+cJ3O8qU9YBAAAAAA==@blueyonder.co.uk>

OK, alright!

Point I was making is that you need to consider what could be needed while you
are designing the system, and
Avoid doing something that will cause problems later - 
So open ended rather than only need that 1 entry

If needed you can split off sets of data from the Animal entry later and put
them into additional tables 
The problem comes if you have setup reports etc that only allow 1 incidence of
something that you find can reporting of require multiple entries.

JimB

=========Stop it! ;)  Not happening -- everything here is a native species
from perfectly normal acquisitions. Most come from rehabbers or rescues. We
don't have exotics. Nothing fancy. :)

Susan H.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From DMcGillivray at ctc.ca.gov  Fri Aug 29 14:14:22 2014
From: DMcGillivray at ctc.ca.gov (McGillivray, Don)
Date: Fri, 29 Aug 2014 19:14:22 +0000
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <98BF9315F59D43B2A908E074F4BB868B@XPS>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<98BF9315F59D43B2A908E074F4BB868B@XPS>
Message-ID: <E48E6D791ED38E4BA54107C7027042471312350C@hqex01.ctc.ca.gov>

Hi Jim,

Your description squares pretty well with my understanding of the appropriate uses for domain aggregates.  Upon closer examination, I discovered that I am using an "in([expression])" clause in the criterion argument of one of my domain aggregate functions, and suspect that that may be having an impact as well.  Basically, I'm seeking the max of the values in a column over a subset of grandchild (GL distribution) records related to a set of records (Payments) that are children to the top level (Deposit) record.  So the call to the function looks something like:

lngMaxUsed = DMax("[SerialNum]","tblGrandChildren","[ParentID] in(SELECT ID from tblParent as par WHERE par.ParentID = " & GrandParentForm!txtID & ")")

Those are not the actual table, column, and control names, but I think you get the idea.  I suspect that the embedded query in the criterion is adding time to the process.  I'm considering adding a column to the grandchild table and populating it with the grandparent ID as the grandchild records are added.  Then the call to DMax() can simply refer to that column instead of having to run the SQL to retrieve the subset of parent records.

Would you concur that the "in([expression])" clause may be the culprit - or at least exacerbating the problem?

Thank you for your response!

Don

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Friday, August 29, 2014 6:03 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Alternatives to domain aggregate functions

Don,

  Just to add a bit to my post from last night as I couldn't see this original post, you've got to be careful where you use Domain functions.

  What they do is just wrap up a SQL Statement so you can execute SQL in
places where you ordinarily can not.   For example, Dlookup() is "SELECT <x>
FROM <y> WHERE <Z>".    So any place you can use SQL directly you should and
a domain function is not appropriate.

 For example, totaling a field in a sub form.   Just place a control in the
footer and set its control source to:  =Sum(<expression>)

 One place where domain functions are really a no-no is inside of a query.
They are totally un-optimizable by the query processor and you are guaranteeing yourself poor performance for anything over a couple of hundred records. 

 Alternatives are executing SQL in code, performing operations on a record
set directly, etc.    

 Domain functions are handy to use, but in general, you'll find that you don't use them often because there are other ways to do things.

Jim.



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don
Sent: Thursday, August 28, 2014 06:28 PM
To: accessD at databaseadvisors.com
Subject: [AccessD] Alternatives to domain aggregate functions

Hi Listers,

I have a form in an Access application (users have the Access 2010 runtime only, on Win 7;  Split FE/BE, with BE on network share) where I need to display and continuously evaluate the cumulative count and value of items and assign an incrementing serial number to child records as they are entered.  At this point, the form uses domain aggregate functions to determine the count and sum of the transactions, and the max plus 1 for the next serial number.  At modest volumes (<=200 records) performance is acceptable.  Beyond that, performance becomes increasingly degraded, to the point of being almost unusable by the time 400 records have been entered.

Obviously, the domain aggregate approach is not working for this situation, so I'm looking for more efficient approaches to fulfill the aggregating/incrementing requirements.  Can anybody point me in a better direction?

Thanks!

Don McGillivray

---------------------------------------------------------------------------
For those interested in further detail, please read on . . .

The application records customer payment data.  Ultimately, the payment data collected by the system will be imported into an Oracle database.  The payments, each consisting of a header record and one or more GL distribution records, are entered in batches that correspond to daily bank deposits.  The payment header record contains the payment date, check number, and amount, and the GL distribution record contains line item detail including an application number and the GL account to which the revenue is booked.  Data entry begins with the creation of a batch (deposit) header record that includes the date, number of payments, number of applications paid for, and total deposit amount.  (The item count and amount are used as "target"
values during data entry to ensure that everything balances in the end.) Once the batch header record is complete, the payment records are entered one at a time, along with their GL details.  So I have a simple hierarchy of data entities: Deposit !
 Header - Payment Header - Payment Details, and the entry form is designed (main form, sub-form, sub-form) to accommodate this structure.  That's the quick and dirty description of the basic setup.

A further wrinkle is that each payment record (child of the top level) is associated to one or more stamp numbers that are affixed to the check upon receipt, and those numbers must be included in the distribution records (grandchildren to the top level) for each payment.  The stamp numbers are composed of a date string (YYMMDD) followed by an incrementing serial number from 1 to n each day, according to the number of applications being paid for.  So, based on the application count of the batch header, a list of stamp numbers can be generated for each batch, and, assuming the checks are entered in stamp number order, the next available number may be assigned automatically to each payment until all are used up.  The entry form allows the user to select from a combo box any valid stamp number for any payment if necessary, but the typical scenario is to allow the system to assign the numbers in sequence to the distribution records automatically.

To help ensure accurate data entry, the user is required to have entered values that agree with the target values.  For example, on a given payment, before a new payment may be entered, the value of the distribution records must equal the check amount as entered in the payment header.  Similarly, the batch itself may not be posted until the sum of its payment records equals the previously entered batch totals (item count and amount.)  These rules are enforced by the form by comparing the batch and payment header entries to the sums of the line items as data is entered.

The application has been in production since May, and has functioned well as designed.  However, this week an unusually large volume of payments (>600) arrived on a single day, and as the batch entry progressed beyond about 300 records, the form's performance became increasingly degraded, until it was essentially unusable.  The degradation is probably due to the methods I've employed to determine the next available stamp number, compounded by the tabulation of the item count and cumulative total for the batch as data entry progresses.  In both cases, I'm using domain aggregate functions to return the count and sum of payments entered, along with the max plus 1 for the next available stamp number.  As the number of records in the batch grows, these calculations take longer and longer.  The effect was observed during development, leading me to modify the table structure so that new records land in temporary tables before being posted by the user to the permanent ones.  This im!
 proved things quite a bit by avoiding the impact of aggregating over a table whose content continues to grow over time, but apparently that move is not enough when the batch volume rises beyond a certain point.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Fri Aug 29 14:20:12 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 15:20:12 -0400
Subject: [AccessD] Normalization discussion
Message-ID: <CA++Sg+d9sFUOYqbh2cPqgkGp7P6voP6B=TtNj7hq9jeF4oym+Q@mail.gmail.com>

<jamesbutton at blueyonder.co.uk> wrote:

> And I would include a searchable comments field on many of the entries so
> you
> can include a short set of notes - such as a "See documents in folder ___"
> Also consider that many of the 'acquired from' places will probably not
> exist,
> or have moved shortly after you get the animals from them - otherwise why
> would
> they not keep the animals
>

==========We're an educational nature center. Everything here is native to
Kentucky. Mostly, they're wildlife that can't be released to the wild and
they come via rehabbers and rescues. Many of those places are well
established, but you're right, they won't always be there, but that would
be true of any business.


>
>
> And - will you be getting offspring from them - that will lead into a
> whole new
> concept of hierarchical entries for descendents of descendents of ...
>

===========I'll be using a self-join for those.

>
> Think of the entries if you're breeding mice - or spiders!
>
> ===========No spiders or insects here, although we do have a few
collections (all dead fortunately). Few of the animals here are allowed to
procreate -- the elk, bison, deer, turkeys, and quail.

Susan H.

From jamesbutton at blueyonder.co.uk  Fri Aug 29 14:41:21 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Fri, 29 Aug 2014 20:41:21 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+d9sFUOYqbh2cPqgkGp7P6voP6B=TtNj7hq9jeF4oym+Q@mail.gmail.com>
References: <CA++Sg+d9sFUOYqbh2cPqgkGp7P6voP6B=TtNj7hq9jeF4oym+Q@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAABKlBzv3Wg1KqtpcY2LoT+cBAAAAAA==@blueyonder.co.uk>

So the database is going to be relatively small so you probably don't need to
consider normalisation 

To my thinking it's pretty much as Rocky posted - practicality!

Avoid having null fields, use minimum, or maximum values as meaning no entry and
boolean (True/False) probably take 2, or 4 bytes where a simple string "Y" or
"N"  value is only 1 char and more understandable.
Avoid requiring any auto-sequencing to be strictly ascending
Create the main entry with a form, then allow that entry to be selected from the
database to create the associated detail 
Also consider timestamps if you need auditing or just ordering of the data
entries.

Just  keep the reporting options open to allow multiple entries of subsidiary
entries.
And - test the reporting as you go along with the design.

And don't forget the backup and recovery planning - 
How are you going to record what happens throughout the days data processing in
order to do a recovery from the previous evening's off-site backup. 

JimB


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Friday, August 29, 2014 8:20 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

<jamesbutton at blueyonder.co.uk> wrote:

> And I would include a searchable comments field on many of the entries so
> you
> can include a short set of notes - such as a "See documents in folder ___"
> Also consider that many of the 'acquired from' places will probably not
> exist,
> or have moved shortly after you get the animals from them - otherwise why
> would
> they not keep the animals
>

==========We're an educational nature center. Everything here is native to
Kentucky. Mostly, they're wildlife that can't be released to the wild and
they come via rehabbers and rescues. Many of those places are well
established, but you're right, they won't always be there, but that would
be true of any business.


>
>
> And - will you be getting offspring from them - that will lead into a
> whole new
> concept of hierarchical entries for descendents of descendents of ...
>

===========I'll be using a self-join for those.

>
> Think of the entries if you're breeding mice - or spiders!
>
> ===========No spiders or insects here, although we do have a few
collections (all dead fortunately). Few of the animals here are allowed to
procreate -- the elk, bison, deer, turkeys, and quail.

Susan H.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From stuart at lexacorp.com.pg  Fri Aug 29 15:42:11 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 30 Aug 2014 06:42:11 +1000
Subject: [AccessD] Normalization discussion
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAABKlBzv3Wg1KqtpcY2LoT+cBAAAAAA==@blueyonder.co.uk>
References: <CA++Sg+d9sFUOYqbh2cPqgkGp7P6voP6B=TtNj7hq9jeF4oym+Q@mail.gmail.com>,
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAABKlBzv3Wg1KqtpcY2LoT+cBAAAAAA==@blueyonder.co.uk>
Message-ID: <5400E5A3.10470.1FD256FE@stuart.lexacorp.com.pg>

A common misunderstanding.

A Boolean takes one bit per field but packed in a byte so 1-8 booleans in a table take 1 byte, 
9016 booleans take 2 bytes etc.. 

A single character in a text field takes four bytes.

Nulls are useful.   Magic boundary values really complicate aggregate functions and should 
be avoided.


-- 
Stuart

On 29 Aug 2014 at 20:41, James Button wrote:

> 
> Avoid having null fields, use minimum, or maximum values as meaning no
> entry and boolean (True/False) probably take 2, or 4 bytes where a
> simple string "Y" or "N"  value is only 1 char and more
> understandable. Avoid requiring any auto-sequencing to be strictly
> ascending Create the main entry with a form, then allow that entry to
> be selected from the database to create the associated detail Also
> consider timestamps if you need auditing or just ordering of the data
> entries.
> 


From stuart at lexacorp.com.pg  Fri Aug 29 15:52:32 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Sat, 30 Aug 2014 06:52:32 +1000
Subject: [AccessD] Normalization discussion
In-Reply-To: <517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>,
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>,
	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
Message-ID: <5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>

I'm pretty much with Rocky on this, for a simple database with a limited number of records, 
having blocks of unused fields  is no "biggie".

But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly in the table, I'd still 
make that a lookup. If you want to make it easy to see in the BE, queries etc make the Key 
characters rather than numeric.  "B,A,E" for example or "LB,A,LE"


-- 
Stuart

On 29 Aug 2014 at 12:02, Rocky Smolin wrote:

> I always engineer my dbs for the constraints of the application and to
> make the user happy.  I do things the easy way - for me. 
> Normalization is great when you're talking 100k rows.  Makes the app
> respond fast.  But I try not to over engineer my apps.
> 
> "A good program is one that works."
> 
> R
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers
> discussion and problem solving Subject: Re: [AccessD] Normalization
> discussion
> 
> Seriously? I would love to do it this way -- nobody but me will ever
> work on it.
> 
> Susan H.
> 
> 
> On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
> 
> > Since this is a small database used by a few people, you can make
> > life easy for yourself.  Put all the  fields you need for each of
> > the three type of acquisition into the Animal table.  I would also
> > not bother with an Acquisition Type table with a PK and an FK in the
> > animal table. Just (gasp) put the words Live Birth, Acquisition, or
> > Law Enforcement right in the Acquisition Type field (text). 
> > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in
> > the back end.
> >
> > In the front end if you want to get fancy, you can appear and/or
> > disappear the different fields you need depending on acquisition
> > type.  Or enable/disable. But not necessary.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Normalization
> > discussion
> >
> > What I'm struggling with today is acquisitions. There are three ways
> > that we acquire an animal -- live birth here at the center, from an
> > institution, or through law enforcement confiscation (almost never
> > happens, but I'm allowing for the possibility). So, each animal has
> > an acquisition type, but depending on the type the subsequent data
> > will be different. For example, if a live birth here at the center,
> > we will also track the dam and sire ids. If we acquire an animal
> > from an institution, we'll track the institution's info, like name,
> > address, phone, and a contact.
> >
> > So, an animal has an acquisition id by type. It's easy to keep an
> > institution and live birth table -- that's no problem. But how do I
> > relate them back to the individual since it can come from two
> > different tables? I think this is probably easier than I'm making
> > it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins
> > <ssharkins at gmail.com> wrote:
> >
> > > Right now, most of my foreign keys in the parent table are simple
> > lookups.
> > > For instance, species -- each individual has a species and those
> > > are in a child table. We'll update that table infrequently -- only
> > > if we add a new species. We have several individuals of each
> > > species. Another is gender -- female and male, but the parent
> > > table has a foreign key to the gender table. (Gender's probably
> > > overkill, but I'm on autopilot I think). I'm also tracking
> > > acquisition method -- there are only three, so again, it's a
> > > lookup table and not a true child
> table.
> > >
> > > Susan H.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust < 
> > > charlotte.foust at gmail.com> wrote:
> > >
> > >> A foreign key is a key that points to the PK in another table.
> > >> You're mixing keys with parent child relationships, which are
> > >> defined through keys.  In a data warehouse, you put a bunch of
> > >> keys in the central table, but in a regular database you put the
> > >> parent PK into the child tables so they know their mommy,  The
> > >> idea is to put the keys
> > where they are needed.
> > >>
> > >> Charlotte
> > >>
> > >>
> > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins 
> > >> <ssharkins at gmail.com>
> > >> wrote:
> > >>
> > >> > I'll spend the morning rereading the book Martin and I wrote,
> > >> > brushing
> > >> up
> > >> > on the normalization part. I've forgotten a lot of the basics.
> > >> > I'm
> > >> writing
> > >> > an animal tracing database in Access and I'm trying to remember
> > >> > if it matters where the fk goes. Now, I remember its purpose
> > >> > and all that,
> > >> but it
> > >> > would be so much simpler if I could just drop them all into the
> > >> > main
> > >> table
> > >> > instead of adding a fk to all the child tables to the main
> > >> > table -- I
> > >> think
> > >> > anyway.
> > >> >
> > >> > So, I've got a main table of animals and all of the remaining
> > >> > tables are child tables of a sort and a few lookup tables. Is
> > >> > it reasonable to just add a fk to all those child tables in my
> > >> > parent
> > table?
> > >> >
> > >> > I just don't remember. I haven't built a database in...
> > >> > seriously... 10 years? It's been long enough that I'm really
> > struggling.
> > >> >
> > >> > Susan H.
> > >> > --
> > >> > AccessD mailing list
> > >> > AccessD at databaseadvisors.com
> > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > >> > Website: http://www.databaseadvisors.com
> > >> >
> > >> --
> > >> AccessD mailing list
> > >> AccessD at databaseadvisors.com
> > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > >> Website: http://www.databaseadvisors.com
> > >>
> > >
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



From ssharkins at gmail.com  Fri Aug 29 16:45:40 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 17:45:40 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <5400E5A3.10470.1FD256FE@stuart.lexacorp.com.pg>
References: <CA++Sg+d9sFUOYqbh2cPqgkGp7P6voP6B=TtNj7hq9jeF4oym+Q@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAABKlBzv3Wg1KqtpcY2LoT+cBAAAAAA==@blueyonder.co.uk>
	<5400E5A3.10470.1FD256FE@stuart.lexacorp.com.pg>
Message-ID: <CA++Sg+f4uxSo9j_vxueQsT-7RDjwDvDH=yim4egv48GfskjUBA@mail.gmail.com>

My rule was -- know what's there and accommodate it. Doesn't matter what it
is, as long as you're consistent and remember the possibility is there.

Susan H.


On Fri, Aug 29, 2014 at 4:42 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> A common misunderstanding.
>
> A Boolean takes one bit per field but packed in a byte so 1-8 booleans in
> a table take 1 byte,
> 9016 booleans take 2 bytes etc..
>
> A single character in a text field takes four bytes.
>
> Nulls are useful.   Magic boundary values really complicate aggregate
> functions and should
> be avoided.
>
>
> --
> Stuart
>
> On 29 Aug 2014 at 20:41, James Button wrote:
>
> >
> > Avoid having null fields, use minimum, or maximum values as meaning no
> > entry and boolean (True/False) probably take 2, or 4 bytes where a
> > simple string "Y" or "N"  value is only 1 char and more
> > understandable. Avoid requiring any auto-sequencing to be strictly
> > ascending Create the main entry with a form, then allow that entry to
> > be selected from the database to create the associated detail Also
> > consider timestamps if you need auditing or just ordering of the data
> > entries.
> >
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From ssharkins at gmail.com  Fri Aug 29 16:47:23 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 29 Aug 2014 17:47:23 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>
	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
	<5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
Message-ID: <CA++Sg+dyhMW2=iSihTujtycWZSO8ub76U=bLgPTWr_MR2Kd7zQ@mail.gmail.com>

I think I've been swayed -- as I stated earlier, I've really been
overthinking this. We just don't have enough animals for this to become
such a headache. I've got the lookups in place and I think I'm going with
the simplified version. :)

Susan H.


On Fri, Aug 29, 2014 at 4:52 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> I'm pretty much with Rocky on this, for a simple database with a limited
> number of records,
> having blocks of unused fields  is no "biggie".
>
> But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly
> in the table, I'd still
> make that a lookup. If you want to make it easy to see in the BE, queries
> etc make the Key
> characters rather than numeric.  "B,A,E" for example or "LB,A,LE"
>
>
> --
> Stuart
>
> On 29 Aug 2014 at 12:02, Rocky Smolin wrote:
>
> > I always engineer my dbs for the constraints of the application and to
> > make the user happy.  I do things the easy way - for me.
> > Normalization is great when you're talking 100k rows.  Makes the app
> > respond fast.  But I try not to over engineer my apps.
> >
> > "A good program is one that works."
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Normalization
> > discussion
> >
> > Seriously? I would love to do it this way -- nobody but me will ever
> > work on it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Since this is a small database used by a few people, you can make
> > > life easy for yourself.  Put all the  fields you need for each of
> > > the three type of acquisition into the Animal table.  I would also
> > > not bother with an Acquisition Type table with a PK and an FK in the
> > > animal table. Just (gasp) put the words Live Birth, Acquisition, or
> > > Law Enforcement right in the Acquisition Type field (text).
> > > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in
> > > the back end.
> > >
> > > In the front end if you want to get fancy, you can appear and/or
> > > disappear the different fields you need depending on acquisition
> > > type.  Or enable/disable. But not necessary.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers
> > > discussion and problem solving Subject: Re: [AccessD] Normalization
> > > discussion
> > >
> > > What I'm struggling with today is acquisitions. There are three ways
> > > that we acquire an animal -- live birth here at the center, from an
> > > institution, or through law enforcement confiscation (almost never
> > > happens, but I'm allowing for the possibility). So, each animal has
> > > an acquisition type, but depending on the type the subsequent data
> > > will be different. For example, if a live birth here at the center,
> > > we will also track the dam and sire ids. If we acquire an animal
> > > from an institution, we'll track the institution's info, like name,
> > > address, phone, and a contact.
> > >
> > > So, an animal has an acquisition id by type. It's easy to keep an
> > > institution and live birth table -- that's no problem. But how do I
> > > relate them back to the individual since it can come from two
> > > different tables? I think this is probably easier than I'm making
> > > it.
> > >
> > > Susan H.
> > >
> > >
> > > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins
> > > <ssharkins at gmail.com> wrote:
> > >
> > > > Right now, most of my foreign keys in the parent table are simple
> > > lookups.
> > > > For instance, species -- each individual has a species and those
> > > > are in a child table. We'll update that table infrequently -- only
> > > > if we add a new species. We have several individuals of each
> > > > species. Another is gender -- female and male, but the parent
> > > > table has a foreign key to the gender table. (Gender's probably
> > > > overkill, but I'm on autopilot I think). I'm also tracking
> > > > acquisition method -- there are only three, so again, it's a
> > > > lookup table and not a true child
> > table.
> > > >
> > > > Susan H.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > > charlotte.foust at gmail.com> wrote:
> > > >
> > > >> A foreign key is a key that points to the PK in another table.
> > > >> You're mixing keys with parent child relationships, which are
> > > >> defined through keys.  In a data warehouse, you put a bunch of
> > > >> keys in the central table, but in a regular database you put the
> > > >> parent PK into the child tables so they know their mommy,  The
> > > >> idea is to put the keys
> > > where they are needed.
> > > >>
> > > >> Charlotte
> > > >>
> > > >>
> > > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins
> > > >> <ssharkins at gmail.com>
> > > >> wrote:
> > > >>
> > > >> > I'll spend the morning rereading the book Martin and I wrote,
> > > >> > brushing
> > > >> up
> > > >> > on the normalization part. I've forgotten a lot of the basics.
> > > >> > I'm
> > > >> writing
> > > >> > an animal tracing database in Access and I'm trying to remember
> > > >> > if it matters where the fk goes. Now, I remember its purpose
> > > >> > and all that,
> > > >> but it
> > > >> > would be so much simpler if I could just drop them all into the
> > > >> > main
> > > >> table
> > > >> > instead of adding a fk to all the child tables to the main
> > > >> > table -- I
> > > >> think
> > > >> > anyway.
> > > >> >
> > > >> > So, I've got a main table of animals and all of the remaining
> > > >> > tables are child tables of a sort and a few lookup tables. Is
> > > >> > it reasonable to just add a fk to all those child tables in my
> > > >> > parent
> > > table?
> > > >> >
> > > >> > I just don't remember. I haven't built a database in...
> > > >> > seriously... 10 years? It's been long enough that I'm really
> > > struggling.
> > > >> >
> > > >> > Susan H.
> > > >> > --
> > > >> > AccessD mailing list
> > > >> > AccessD at databaseadvisors.com
> > > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> > Website: http://www.databaseadvisors.com
> > > >> >
> > > >> --
> > > >> AccessD mailing list
> > > >> AccessD at databaseadvisors.com
> > > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> Website: http://www.databaseadvisors.com
> > > >>
> > > >
> > > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From rockysmolin at bchacc.com  Fri Aug 29 17:59:05 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Fri, 29 Aug 2014 15:59:05 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>,
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>,
	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
	<5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
Message-ID: <3244060F337F43EF93D8CFEB516BFFC2@HAL9007>

My understanding - from this list btw :o) is that a field in a record
doesn't take any space until you put some data into it.  So having an empty
field in 9900 of 10,000 records doesn't matter because it doesn't take any
space - or relatively little?

R


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Friday, August 29, 2014 1:53 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

I'm pretty much with Rocky on this, for a simple database with a limited
number of records, having blocks of unused fields  is no "biggie".

But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly
in the table, I'd still make that a lookup. If you want to make it easy to
see in the BE, queries etc make the Key characters rather than numeric.
"B,A,E" for example or "LB,A,LE"


--
Stuart

On 29 Aug 2014 at 12:02, Rocky Smolin wrote:

> I always engineer my dbs for the constraints of the application and to 
> make the user happy.  I do things the easy way - for me.
> Normalization is great when you're talking 100k rows.  Makes the app 
> respond fast.  But I try not to over engineer my apps.
> 
> "A good program is one that works."
> 
> R
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan 
> Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers 
> discussion and problem solving Subject: Re: [AccessD] Normalization 
> discussion
> 
> Seriously? I would love to do it this way -- nobody but me will ever 
> work on it.
> 
> Susan H.
> 
> 
> On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
> 
> > Since this is a small database used by a few people, you can make 
> > life easy for yourself.  Put all the  fields you need for each of 
> > the three type of acquisition into the Animal table.  I would also 
> > not bother with an Acquisition Type table with a PK and an FK in the 
> > animal table. Just (gasp) put the words Live Birth, Acquisition, or 
> > Law Enforcement right in the Acquisition Type field (text).
> > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in 
> > the back end.
> >
> > In the front end if you want to get fancy, you can appear and/or 
> > disappear the different fields you need depending on acquisition 
> > type.  Or enable/disable. But not necessary.
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan 
> > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers 
> > discussion and problem solving Subject: Re: [AccessD] Normalization 
> > discussion
> >
> > What I'm struggling with today is acquisitions. There are three ways 
> > that we acquire an animal -- live birth here at the center, from an 
> > institution, or through law enforcement confiscation (almost never 
> > happens, but I'm allowing for the possibility). So, each animal has 
> > an acquisition type, but depending on the type the subsequent data 
> > will be different. For example, if a live birth here at the center, 
> > we will also track the dam and sire ids. If we acquire an animal 
> > from an institution, we'll track the institution's info, like name, 
> > address, phone, and a contact.
> >
> > So, an animal has an acquisition id by type. It's easy to keep an 
> > institution and live birth table -- that's no problem. But how do I 
> > relate them back to the individual since it can come from two 
> > different tables? I think this is probably easier than I'm making 
> > it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins 
> > <ssharkins at gmail.com> wrote:
> >
> > > Right now, most of my foreign keys in the parent table are simple
> > lookups.
> > > For instance, species -- each individual has a species and those 
> > > are in a child table. We'll update that table infrequently -- only 
> > > if we add a new species. We have several individuals of each 
> > > species. Another is gender -- female and male, but the parent 
> > > table has a foreign key to the gender table. (Gender's probably 
> > > overkill, but I'm on autopilot I think). I'm also tracking 
> > > acquisition method -- there are only three, so again, it's a 
> > > lookup table and not a true child
> table.
> > >
> > > Susan H.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust < 
> > > charlotte.foust at gmail.com> wrote:
> > >
> > >> A foreign key is a key that points to the PK in another table.
> > >> You're mixing keys with parent child relationships, which are 
> > >> defined through keys.  In a data warehouse, you put a bunch of 
> > >> keys in the central table, but in a regular database you put the 
> > >> parent PK into the child tables so they know their mommy,  The 
> > >> idea is to put the keys
> > where they are needed.
> > >>
> > >> Charlotte
> > >>
> > >>
> > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins 
> > >> <ssharkins at gmail.com>
> > >> wrote:
> > >>
> > >> > I'll spend the morning rereading the book Martin and I wrote, 
> > >> > brushing
> > >> up
> > >> > on the normalization part. I've forgotten a lot of the basics.
> > >> > I'm
> > >> writing
> > >> > an animal tracing database in Access and I'm trying to remember 
> > >> > if it matters where the fk goes. Now, I remember its purpose 
> > >> > and all that,
> > >> but it
> > >> > would be so much simpler if I could just drop them all into the 
> > >> > main
> > >> table
> > >> > instead of adding a fk to all the child tables to the main 
> > >> > table -- I
> > >> think
> > >> > anyway.
> > >> >
> > >> > So, I've got a main table of animals and all of the remaining 
> > >> > tables are child tables of a sort and a few lookup tables. Is 
> > >> > it reasonable to just add a fk to all those child tables in my 
> > >> > parent
> > table?
> > >> >
> > >> > I just don't remember. I haven't built a database in...
> > >> > seriously... 10 years? It's been long enough that I'm really
> > struggling.
> > >> >
> > >> > Susan H.
> > >> > --
> > >> > AccessD mailing list
> > >> > AccessD at databaseadvisors.com
> > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > >> > Website: http://www.databaseadvisors.com
> > >> >
> > >> --
> > >> AccessD mailing list
> > >> AccessD at databaseadvisors.com
> > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > >> Website: http://www.databaseadvisors.com
> > >>
> > >
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From charlotte.foust at gmail.com  Sat Aug 30 00:39:15 2014
From: charlotte.foust at gmail.com (Charlotte Foust)
Date: Fri, 29 Aug 2014 22:39:15 -0700
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CAH+Met8s9d+dXB0GO4vOL+TJGG5Tj0h36N_Htk0Zw-rvAWZ_XA@mail.gmail.com>
	<CA++Sg+ehiKXVVyT39MGaMa+WbbCYJBuyX=JdzRsBgAvAVJ-o5A@mail.gmail.com>
Message-ID: <CAH+Met9XoGNjJD7MKgBVH0Fo7zGwMwewqMM+pZt+5FgdOaezpg@mail.gmail.com>

You've got the relationship confused.   With lookup tables,  they're the
parent while the main data table is the child side of the relationship.
You DO put those FKs in the main table.

Charlotte
On Aug 29, 2014 8:42 AM, "Susan Harkins" <ssharkins at gmail.com> wrote:

> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are in a
> child table. We'll update that table infrequently -- only if we add a new
> species. We have several individuals of each species. Another is gender --
> female and male, but the parent table has a foreign key to the gender
> table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
> tracking acquisition method -- there are only three, so again, it's a
> lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com
> > wrote:
>
> > A foreign key is a key that points to the PK in another table.  You're
> > mixing keys with parent child relationships, which are defined through
> > keys.  In a data warehouse, you put a bunch of keys in the central table,
> > but in a regular database you put the parent PK into the child tables so
> > they know their mommy,  The idea is to put the keys where they are
> needed.
> >
> > Charlotte
> >
> >
> > On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> > wrote:
> >
> > > I'll spend the morning rereading the book Martin and I wrote, brushing
> up
> > > on the normalization part. I've forgotten a lot of the basics. I'm
> > writing
> > > an animal tracing database in Access and I'm trying to remember if it
> > > matters where the fk goes. Now, I remember its purpose and all that,
> but
> > it
> > > would be so much simpler if I could just drop them all into the main
> > table
> > > instead of adding a fk to all the child tables to the main table -- I
> > think
> > > anyway.
> > >
> > > So, I've got a main table of animals and all of the remaining tables
> are
> > > child tables of a sort and a few lookup tables. Is it reasonable to
> just
> > > add a fk to all those child tables in my parent table?
> > >
> > > I just don't remember. I haven't built a database in... seriously... 10
> > > years? It's been long enough that I'm really struggling.
> > >
> > > Susan H.
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From ssharkins at gmail.com  Sat Aug 30 07:44:24 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Sat, 30 Aug 2014 08:44:24 -0400
Subject: [AccessD] Normalization discussion
Message-ID: <CA++Sg+dYS9OvdhQkmmCEY=TuwXqmQufDmGtnqyFRiM60aVDJUQ@mail.gmail.com>

Good to know I got something right. :)
Susan H.

With lookup tables,  they're the
> parent while the main data table is the child side of the relationship.
> You DO put those FKs in the main table.
>
> Charlotte
>

From ssharkins at gmail.com  Sat Aug 30 07:53:30 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Sat, 30 Aug 2014 08:53:30 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>
	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
	<5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
Message-ID: <CA++Sg+coneJfJv3_Hzg1MZfmv1QCwZEqzvqc3JkocBh5KEVmRw@mail.gmail.com>

We have less than 50.

Susan H.


On Fri, Aug 29, 2014 at 4:52 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> I'm pretty much with Rocky on this, for a simple database with a limited
> number of records,
> having blocks of unused fields  is no "biggie".
>
> But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly
> in the table, I'd still
> make that a lookup. If you want to make it easy to see in the BE, queries
> etc make the Key
> characters rather than numeric.  "B,A,E" for example or "LB,A,LE"
>
>
> --
> Stuart
>
> On 29 Aug 2014 at 12:02, Rocky Smolin wrote:
>
> > I always engineer my dbs for the constraints of the application and to
> > make the user happy.  I do things the easy way - for me.
> > Normalization is great when you're talking 100k rows.  Makes the app
> > respond fast.  But I try not to over engineer my apps.
> >
> > "A good program is one that works."
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Normalization
> > discussion
> >
> > Seriously? I would love to do it this way -- nobody but me will ever
> > work on it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Since this is a small database used by a few people, you can make
> > > life easy for yourself.  Put all the  fields you need for each of
> > > the three type of acquisition into the Animal table.  I would also
> > > not bother with an Acquisition Type table with a PK and an FK in the
> > > animal table. Just (gasp) put the words Live Birth, Acquisition, or
> > > Law Enforcement right in the Acquisition Type field (text).
> > > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in
> > > the back end.
> > >
> > > In the front end if you want to get fancy, you can appear and/or
> > > disappear the different fields you need depending on acquisition
> > > type.  Or enable/disable. But not necessary.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers
> > > discussion and problem solving Subject: Re: [AccessD] Normalization
> > > discussion
> > >
> > > What I'm struggling with today is acquisitions. There are three ways
> > > that we acquire an animal -- live birth here at the center, from an
> > > institution, or through law enforcement confiscation (almost never
> > > happens, but I'm allowing for the possibility). So, each animal has
> > > an acquisition type, but depending on the type the subsequent data
> > > will be different. For example, if a live birth here at the center,
> > > we will also track the dam and sire ids. If we acquire an animal
> > > from an institution, we'll track the institution's info, like name,
> > > address, phone, and a contact.
> > >
> > > So, an animal has an acquisition id by type. It's easy to keep an
> > > institution and live birth table -- that's no problem. But how do I
> > > relate them back to the individual since it can come from two
> > > different tables? I think this is probably easier than I'm making
> > > it.
> > >
> > > Susan H.
> > >
> > >
> > > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins
> > > <ssharkins at gmail.com> wrote:
> > >
> > > > Right now, most of my foreign keys in the parent table are simple
> > > lookups.
> > > > For instance, species -- each individual has a species and those
> > > > are in a child table. We'll update that table infrequently -- only
> > > > if we add a new species. We have several individuals of each
> > > > species. Another is gender -- female and male, but the parent
> > > > table has a foreign key to the gender table. (Gender's probably
> > > > overkill, but I'm on autopilot I think). I'm also tracking
> > > > acquisition method -- there are only three, so again, it's a
> > > > lookup table and not a true child
> > table.
> > > >
> > > > Susan H.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > > charlotte.foust at gmail.com> wrote:
> > > >
> > > >> A foreign key is a key that points to the PK in another table.
> > > >> You're mixing keys with parent child relationships, which are
> > > >> defined through keys.  In a data warehouse, you put a bunch of
> > > >> keys in the central table, but in a regular database you put the
> > > >> parent PK into the child tables so they know their mommy,  The
> > > >> idea is to put the keys
> > > where they are needed.
> > > >>
> > > >> Charlotte
> > > >>
> > > >>
> > > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins
> > > >> <ssharkins at gmail.com>
> > > >> wrote:
> > > >>
> > > >> > I'll spend the morning rereading the book Martin and I wrote,
> > > >> > brushing
> > > >> up
> > > >> > on the normalization part. I've forgotten a lot of the basics.
> > > >> > I'm
> > > >> writing
> > > >> > an animal tracing database in Access and I'm trying to remember
> > > >> > if it matters where the fk goes. Now, I remember its purpose
> > > >> > and all that,
> > > >> but it
> > > >> > would be so much simpler if I could just drop them all into the
> > > >> > main
> > > >> table
> > > >> > instead of adding a fk to all the child tables to the main
> > > >> > table -- I
> > > >> think
> > > >> > anyway.
> > > >> >
> > > >> > So, I've got a main table of animals and all of the remaining
> > > >> > tables are child tables of a sort and a few lookup tables. Is
> > > >> > it reasonable to just add a fk to all those child tables in my
> > > >> > parent
> > > table?
> > > >> >
> > > >> > I just don't remember. I haven't built a database in...
> > > >> > seriously... 10 years? It's been long enough that I'm really
> > > struggling.
> > > >> >
> > > >> > Susan H.
> > > >> > --
> > > >> > AccessD mailing list
> > > >> > AccessD at databaseadvisors.com
> > > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> > Website: http://www.databaseadvisors.com
> > > >> >
> > > >> --
> > > >> AccessD mailing list
> > > >> AccessD at databaseadvisors.com
> > > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> Website: http://www.databaseadvisors.com
> > > >>
> > > >
> > > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

From jimdettman at verizon.net  Sat Aug 30 10:12:28 2014
From: jimdettman at verizon.net (Jim Dettman)
Date: Sat, 30 Aug 2014 11:12:28 -0400
Subject: [AccessD] Normalization discussion
In-Reply-To: <CA++Sg+coneJfJv3_Hzg1MZfmv1QCwZEqzvqc3JkocBh5KEVmRw@mail.gmail.com>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>
	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>
	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>
	<5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>
	<CA++Sg+coneJfJv3_Hzg1MZfmv1QCwZEqzvqc3JkocBh5KEVmRw@mail.gmail.com>
Message-ID: <3C71F77958E74652A412319ECE4EE739@XPS>

Susan,

 I'd say I have to be the dissenting voice. 

 While I understand the constraints, that this is small, you will be the
only one working on it, etc, you do want to try and do it as right as
possible because as we all know on this list, many things have a habit of
turning into much more.

 I agree with the others; just list out everything you want to know about
these animals, and then go from there.

 For example, every animal has a father and mother.  You may not know it
because it was an acquisition or that it came from law enforcement, but it
does have one, you just don't know it.  That's where a null comes in and is
the difference between not having an attribute and not knowing the value for
it.   So me, I would have a sire and dam FK fields in the animal record and
they remain null for anything other than a live birth.

 All records in a table should have the same "shape".  That is, you should
be able to fill in a value for every column (assuming you know it).   If you
cannot to that for a record, then your describing more than one "thing" in
your table.

 I think by the time you make up your list, break things up into groups,
you'll find it's just common sense.

 But to forgo normalization entirely will give you a database that is
difficult to work on, have poor performance, and other issues.

If your going to go that route, you might as well use a spreadsheet.

Jim.

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Saturday, August 30, 2014 08:54 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

We have less than 50.

Susan H.


On Fri, Aug 29, 2014 at 4:52 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> I'm pretty much with Rocky on this, for a simple database with a limited
> number of records,
> having blocks of unused fields  is no "biggie".
>
> But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly
> in the table, I'd still
> make that a lookup. If you want to make it easy to see in the BE, queries
> etc make the Key
> characters rather than numeric.  "B,A,E" for example or "LB,A,LE"
>
>
> --
> Stuart
>
> On 29 Aug 2014 at 12:02, Rocky Smolin wrote:
>
> > I always engineer my dbs for the constraints of the application and to
> > make the user happy.  I do things the easy way - for me.
> > Normalization is great when you're talking 100k rows.  Makes the app
> > respond fast.  But I try not to over engineer my apps.
> >
> > "A good program is one that works."
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Normalization
> > discussion
> >
> > Seriously? I would love to do it this way -- nobody but me will ever
> > work on it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Since this is a small database used by a few people, you can make
> > > life easy for yourself.  Put all the  fields you need for each of
> > > the three type of acquisition into the Animal table.  I would also
> > > not bother with an Acquisition Type table with a PK and an FK in the
> > > animal table. Just (gasp) put the words Live Birth, Acquisition, or
> > > Law Enforcement right in the Acquisition Type field (text).
> > > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in
> > > the back end.
> > >
> > > In the front end if you want to get fancy, you can appear and/or
> > > disappear the different fields you need depending on acquisition
> > > type.  Or enable/disable. But not necessary.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers
> > > discussion and problem solving Subject: Re: [AccessD] Normalization
> > > discussion
> > >
> > > What I'm struggling with today is acquisitions. There are three ways
> > > that we acquire an animal -- live birth here at the center, from an
> > > institution, or through law enforcement confiscation (almost never
> > > happens, but I'm allowing for the possibility). So, each animal has
> > > an acquisition type, but depending on the type the subsequent data
> > > will be different. For example, if a live birth here at the center,
> > > we will also track the dam and sire ids. If we acquire an animal
> > > from an institution, we'll track the institution's info, like name,
> > > address, phone, and a contact.
> > >
> > > So, an animal has an acquisition id by type. It's easy to keep an
> > > institution and live birth table -- that's no problem. But how do I
> > > relate them back to the individual since it can come from two
> > > different tables? I think this is probably easier than I'm making
> > > it.
> > >
> > > Susan H.
> > >
> > >
> > > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins
> > > <ssharkins at gmail.com> wrote:
> > >
> > > > Right now, most of my foreign keys in the parent table are simple
> > > lookups.
> > > > For instance, species -- each individual has a species and those
> > > > are in a child table. We'll update that table infrequently -- only
> > > > if we add a new species. We have several individuals of each
> > > > species. Another is gender -- female and male, but the parent
> > > > table has a foreign key to the gender table. (Gender's probably
> > > > overkill, but I'm on autopilot I think). I'm also tracking
> > > > acquisition method -- there are only three, so again, it's a
> > > > lookup table and not a true child
> > table.
> > > >
> > > > Susan H.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > > charlotte.foust at gmail.com> wrote:
> > > >
> > > >> A foreign key is a key that points to the PK in another table.
> > > >> You're mixing keys with parent child relationships, which are
> > > >> defined through keys.  In a data warehouse, you put a bunch of
> > > >> keys in the central table, but in a regular database you put the
> > > >> parent PK into the child tables so they know their mommy,  The
> > > >> idea is to put the keys
> > > where they are needed.
> > > >>
> > > >> Charlotte
> > > >>
> > > >>
> > > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins
> > > >> <ssharkins at gmail.com>
> > > >> wrote:
> > > >>
> > > >> > I'll spend the morning rereading the book Martin and I wrote,
> > > >> > brushing
> > > >> up
> > > >> > on the normalization part. I've forgotten a lot of the basics.
> > > >> > I'm
> > > >> writing
> > > >> > an animal tracing database in Access and I'm trying to remember
> > > >> > if it matters where the fk goes. Now, I remember its purpose
> > > >> > and all that,
> > > >> but it
> > > >> > would be so much simpler if I could just drop them all into the
> > > >> > main
> > > >> table
> > > >> > instead of adding a fk to all the child tables to the main
> > > >> > table -- I
> > > >> think
> > > >> > anyway.
> > > >> >
> > > >> > So, I've got a main table of animals and all of the remaining
> > > >> > tables are child tables of a sort and a few lookup tables. Is
> > > >> > it reasonable to just add a fk to all those child tables in my
> > > >> > parent
> > > table?
> > > >> >
> > > >> > I just don't remember. I haven't built a database in...
> > > >> > seriously... 10 years? It's been long enough that I'm really
> > > struggling.
> > > >> >
> > > >> > Susan H.
> > > >> > --
> > > >> > AccessD mailing list
> > > >> > AccessD at databaseadvisors.com
> > > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> > Website: http://www.databaseadvisors.com
> > > >> >
> > > >> --
> > > >> AccessD mailing list
> > > >> AccessD at databaseadvisors.com
> > > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> Website: http://www.databaseadvisors.com
> > > >>
> > > >
> > > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From jamesbutton at blueyonder.co.uk  Sat Aug 30 10:42:28 2014
From: jamesbutton at blueyonder.co.uk (James Button)
Date: Sat, 30 Aug 2014 16:42:28 +0100
Subject: [AccessD] Normalization discussion
In-Reply-To: <3C71F77958E74652A412319ECE4EE739@XPS>
References: <CA++Sg+cFxRV_FywAXWgxAnKX+jC+Xs0rajp06KUwOZVAvT4CUQ@mail.gmail.com>	<CA++Sg+e=GB2y=jGcoOZpVCH_-mBNrg=VwcX_xi8mDLg4tYKRBQ@mail.gmail.com>	<517E7EEBD19F446EA92C3FCBE2102A8B@HAL9007>	<5400E810.27278.1FDBCE9D@stuart.lexacorp.com.pg>	<CA++Sg+coneJfJv3_Hzg1MZfmv1QCwZEqzvqc3JkocBh5KEVmRw@mail.gmail.com>
	<3C71F77958E74652A412319ECE4EE739@XPS>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAO8VDlNCBfdEkctCy61lm0HCgAAAEAAAAD7c6FWGDmpAs6xfwx+UqP0BAAAAAA==@blueyonder.co.uk>

No - not a spreadsheet 
Spreadsheets is for summarizing and manipulating data 
Yes they can b used as a data store, 
but data validation against lists is a pain
Data integrity is a pain

Databases ( and that's wot this group is for) 
Allow reasonably easy form creation for data entry
Allow referential integrity 
Have better management for more than 1 person to access the data at a time.

Yes - if you want the data in a spreadsheet - you can define the data in an
Excel  spreadsheet to be in a table and use SQL to access it from the database.

But it's much better to manage the sort of data you have in a database - well
you apparently have a copy of Access so don't even have the up-front monetary
consideration.

Also - having the sire and dam as FK for the progeny of your recorded animals
allows you to locate all the offspring of a particular parent and add in
levelling for hereditary chart.
It also means that you should consider creating at the least a sparsely
populated entry for the sire and dam if you have sufficient detail 

So much to consider - but most of it is add'able to a basic structure, after you
have that set-up.

JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Saturday, August 30, 2014 4:12 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Normalization discussion

Susan,

 I'd say I have to be the dissenting voice. 

 While I understand the constraints, that this is small, you will be the
only one working on it, etc, you do want to try and do it as right as
possible because as we all know on this list, many things have a habit of
turning into much more.

 I agree with the others; just list out everything you want to know about
these animals, and then go from there.

 For example, every animal has a father and mother.  You may not know it
because it was an acquisition or that it came from law enforcement, but it
does have one, you just don't know it.  That's where a null comes in and is
the difference between not having an attribute and not knowing the value for
it.   So me, I would have a sire and dam FK fields in the animal record and
they remain null for anything other than a live birth.

 All records in a table should have the same "shape".  That is, you should
be able to fill in a value for every column (assuming you know it).   If you
cannot to that for a record, then your describing more than one "thing" in
your table.

 I think by the time you make up your list, break things up into groups,
you'll find it's just common sense.

 But to forgo normalization entirely will give you a database that is
difficult to work on, have poor performance, and other issues.

If your going to go that route, you might as well use a spreadsheet.

Jim.

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Saturday, August 30, 2014 08:54 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Normalization discussion

We have less than 50.

Susan H.


On Fri, Aug 29, 2014 at 4:52 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> I'm pretty much with Rocky on this, for a simple database with a limited
> number of records,
> having blocks of unused fields  is no "biggie".
>
> But I  wouldn't store  "Live Birth, Acquisition, Law Enforcement" directly
> in the table, I'd still
> make that a lookup. If you want to make it easy to see in the BE, queries
> etc make the Key
> characters rather than numeric.  "B,A,E" for example or "LB,A,LE"
>
>
> --
> Stuart
>
> On 29 Aug 2014 at 12:02, Rocky Smolin wrote:
>
> > I always engineer my dbs for the constraints of the application and to
> > make the user happy.  I do things the easy way - for me.
> > Normalization is great when you're talking 100k rows.  Makes the app
> > respond fast.  But I try not to over engineer my apps.
> >
> > "A good program is one that works."
> >
> > R
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > Harkins Sent: Friday, August 29, 2014 11:52 AM To: Access Developers
> > discussion and problem solving Subject: Re: [AccessD] Normalization
> > discussion
> >
> > Seriously? I would love to do it this way -- nobody but me will ever
> > work on it.
> >
> > Susan H.
> >
> >
> > On Fri, Aug 29, 2014 at 2:42 PM, Rocky Smolin <rockysmolin at bchacc.com>
> > wrote:
> >
> > > Since this is a small database used by a few people, you can make
> > > life easy for yourself.  Put all the  fields you need for each of
> > > the three type of acquisition into the Animal table.  I would also
> > > not bother with an Acquisition Type table with a PK and an FK in the
> > > animal table. Just (gasp) put the words Live Birth, Acquisition, or
> > > Law Enforcement right in the Acquisition Type field (text).
> > > Unnormalized?  Yes.  Simple?  Yes.  And easy to see when you look in
> > > the back end.
> > >
> > > In the front end if you want to get fancy, you can appear and/or
> > > disappear the different fields you need depending on acquisition
> > > type.  Or enable/disable. But not necessary.
> > >
> > > R
> > >
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan
> > > Harkins Sent: Friday, August 29, 2014 10:54 AM To: Access Developers
> > > discussion and problem solving Subject: Re: [AccessD] Normalization
> > > discussion
> > >
> > > What I'm struggling with today is acquisitions. There are three ways
> > > that we acquire an animal -- live birth here at the center, from an
> > > institution, or through law enforcement confiscation (almost never
> > > happens, but I'm allowing for the possibility). So, each animal has
> > > an acquisition type, but depending on the type the subsequent data
> > > will be different. For example, if a live birth here at the center,
> > > we will also track the dam and sire ids. If we acquire an animal
> > > from an institution, we'll track the institution's info, like name,
> > > address, phone, and a contact.
> > >
> > > So, an animal has an acquisition id by type. It's easy to keep an
> > > institution and live birth table -- that's no problem. But how do I
> > > relate them back to the individual since it can come from two
> > > different tables? I think this is probably easier than I'm making
> > > it.
> > >
> > > Susan H.
> > >
> > >
> > > On Fri, Aug 29, 2014 at 11:39 AM, Susan Harkins
> > > <ssharkins at gmail.com> wrote:
> > >
> > > > Right now, most of my foreign keys in the parent table are simple
> > > lookups.
> > > > For instance, species -- each individual has a species and those
> > > > are in a child table. We'll update that table infrequently -- only
> > > > if we add a new species. We have several individuals of each
> > > > species. Another is gender -- female and male, but the parent
> > > > table has a foreign key to the gender table. (Gender's probably
> > > > overkill, but I'm on autopilot I think). I'm also tracking
> > > > acquisition method -- there are only three, so again, it's a
> > > > lookup table and not a true child
> > table.
> > > >
> > > > Susan H.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> > > > charlotte.foust at gmail.com> wrote:
> > > >
> > > >> A foreign key is a key that points to the PK in another table.
> > > >> You're mixing keys with parent child relationships, which are
> > > >> defined through keys.  In a data warehouse, you put a bunch of
> > > >> keys in the central table, but in a regular database you put the
> > > >> parent PK into the child tables so they know their mommy,  The
> > > >> idea is to put the keys
> > > where they are needed.
> > > >>
> > > >> Charlotte
> > > >>
> > > >>
> > > >> On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins
> > > >> <ssharkins at gmail.com>
> > > >> wrote:
> > > >>
> > > >> > I'll spend the morning rereading the book Martin and I wrote,
> > > >> > brushing
> > > >> up
> > > >> > on the normalization part. I've forgotten a lot of the basics.
> > > >> > I'm
> > > >> writing
> > > >> > an animal tracing database in Access and I'm trying to remember
> > > >> > if it matters where the fk goes. Now, I remember its purpose
> > > >> > and all that,
> > > >> but it
> > > >> > would be so much simpler if I could just drop them all into the
> > > >> > main
> > > >> table
> > > >> > instead of adding a fk to all the child tables to the main
> > > >> > table -- I
> > > >> think
> > > >> > anyway.
> > > >> >
> > > >> > So, I've got a main table of animals and all of the remaining
> > > >> > tables are child tables of a sort and a few lookup tables. Is
> > > >> > it reasonable to just add a fk to all those child tables in my
> > > >> > parent
> > > table?
> > > >> >
> > > >> > I just don't remember. I haven't built a database in...
> > > >> > seriously... 10 years? It's been long enough that I'm really
> > > struggling.
> > > >> >
> > > >> > Susan H.
> > > >> > --
> > > >> > AccessD mailing list
> > > >> > AccessD at databaseadvisors.com
> > > >> > http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> > Website: http://www.databaseadvisors.com
> > > >> >
> > > >> --
> > > >> AccessD mailing list
> > > >> AccessD at databaseadvisors.com
> > > >> http://databaseadvisors.com/mailman/listinfo/accessd
> > > >> Website: http://www.databaseadvisors.com
> > > >>
> > > >
> > > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


From ssharkins at gmail.com  Sat Aug 30 15:09:11 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Sat, 30 Aug 2014 16:09:11 -0400
Subject: [AccessD] Normalization discussion
Message-ID: <CA++Sg+fREJaT6JXji_BfauJErxsPYLQOckN5JRoi+8VU=y1Q4g@mail.gmail.com>

>
>  For example, every animal has a father and mother.  You may not know it
> because it was an acquisition or that it came from law enforcement, but it
> does have one, you just don't know it.  That's where a null comes in and is
> the difference between not having an attribute and not knowing the value
> for
> it.   So me, I would have a sire and dam FK fields in the animal record and
> they remain null for anything other than a live birth.
>

===========An excellent idea and one that I hadn't considered. Thank you.

>
>  All records in a table should have the same "shape".  That is, you should
> be able to fill in a value for every column (assuming you know it).   If
> you
> cannot to that for a record, then your describing more than one "thing" in
> your table.
>

===========This is already done and I'm comfortable with the table
structure.

>
>  I think by the time you make up your list, break things up into groups,
> you'll find it's just common sense.
>
>  But to forgo normalization entirely will give you a database that is
> difficult to work on, have poor performance, and other issues.
>
>
===========I'm not going to do that. :) But, I am feeling better about
taking small shortcuts -- just like the one you mentioned above. I was
making it way too hard.

Thanks!

Susan H.

From marksimms at verizon.net  Sun Aug 31 15:56:48 2014
From: marksimms at verizon.net (Mark Simms)
Date: Sun, 31 Aug 2014 16:56:48 -0400
Subject: [AccessD] Alternatives to domain aggregate functions
In-Reply-To: <CAEPJO1i3G=JsZ6rC_pGxmDfyUyR3VV_z66tDguwAowc+GK87Nw@mail.gmail.com>
References: <E48E6D791ED38E4BA54107C702704247131231D7@hqex01.ctc.ca.gov>
	<98BF9315F59D43B2A908E074F4BB868B@XPS>
	<CAEPJO1i3G=JsZ6rC_pGxmDfyUyR3VV_z66tDguwAowc+GK87Nw@mail.gmail.com>
Message-ID: <00b401cfc55e$158ddc90$40a995b0$@net>

Re: "Obviously, the domain aggregate approach is not working for this
> situation, so I'm looking for more efficient approaches to fulfill the
> aggregating/incrementing requirements."

No need to change databases....just replace the aggregate functions with
standard DAO queries.

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:accessd-
> bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Friday, August 29, 2014 11:00 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Alternatives to domain aggregate functions
>
> Jim.
>
> Excellent summary, and I would add a couple of points:
>
> If at all possible, lose the Access Back End (BE) and replace it with
> either the free edition of MS-SQL or MySQL or MariaDb. In all cases the
> increase in performance is significant, and many times dramatic.
> Basically,
> the larger the number of users, the more dramatic the increase in
> performance.
>
> Having made that move, then the next logical place to go is Stored
> Procedures rather than Access queries. In my many years as a developer,
> I
> have seen very few occasions where dynamic construction of a SQL query
> was
> the only solution. About 99% of the time, it is unnecessary. A little
> thought and the use of optional parameters to an SP is the better way.
>
> Arthur
>
>
> On Fri, Aug 29, 2014 at 9:02 AM, Jim Dettman <jimdettman at verizon.net>
> wrote:
>
> > Don,
> >
> >   Just to add a bit to my post from last night as I couldn't see this
> > original post, you've got to be careful where you use Domain
> functions.
> >
> >   What they do is just wrap up a SQL Statement so you can execute SQL
> in
> > places where you ordinarily can not.   For example, Dlookup() is
> "SELECT
> > <x>
> > FROM <y> WHERE <Z>".    So any place you can use SQL directly you
> should
> > and
> > a domain function is not appropriate.
> >
> >  For example, totaling a field in a sub form.   Just place a control
> in the
> > footer and set its control source to:  =Sum(<expression>)
> >
> >  One place where domain functions are really a no-no is inside of a
> query.
> > They are totally un-optimizable by the query processor and you are
> > guaranteeing yourself poor performance for anything over a couple of
> > hundred
> > records.
> >
> >  Alternatives are executing SQL in code, performing operations on a
> record
> > set directly, etc.
> >
> >  Domain functions are handy to use, but in general, you'll find that
> you
> > don't use them often because there are other ways to do things.
> >
> > Jim.
> >
> >
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> McGillivray,
> > Don
> > Sent: Thursday, August 28, 2014 06:28 PM
> > To: accessD at databaseadvisors.com
> > Subject: [AccessD] Alternatives to domain aggregate functions
> >
> > Hi Listers,
> >
> > I have a form in an Access application (users have the Access 2010
> runtime
> > only, on Win 7;  Split FE/BE, with BE on network share) where I need
> to
> > display and continuously evaluate the cumulative count and value of
> items
> > and assign an incrementing serial number to child records as they are
> > entered.  At this point, the form uses domain aggregate functions to
> > determine the count and sum of the transactions, and the max plus 1
> for the
> > next serial number.  At modest volumes (<=200 records) performance is
> > acceptable.  Beyond that, performance becomes increasingly degraded,
> to the
> > point of being almost unusable by the time 400 records have been
> entered.
> >
> > Obviously, the domain aggregate approach is not working for this
> situation,
> > so I'm looking for more efficient approaches to fulfill the
> > aggregating/incrementing requirements.  Can anybody point me in a
> better
> > direction?
> >
> > Thanks!
> >
> > Don McGillivray
> >
> > ---------------------------------------------------------------------
> ------
> > For those interested in further detail, please read on . . .
> >
> > The application records customer payment data.  Ultimately, the
> payment
> > data
> > collected by the system will be imported into an Oracle database.
> The
> > payments, each consisting of a header record and one or more GL
> > distribution
> > records, are entered in batches that correspond to daily bank
> deposits.
> > The
> > payment header record contains the payment date, check number, and
> amount,
> > and the GL distribution record contains line item detail including an
> > application number and the GL account to which the revenue is booked.
> Data
> > entry begins with the creation of a batch (deposit) header record
> that
> > includes the date, number of payments, number of applications paid
> for, and
> > total deposit amount.  (The item count and amount are used as
> "target"
> > values during data entry to ensure that everything balances in the
> end.)
> > Once the batch header record is complete, the payment records are
> entered
> > one at a time, along with their GL details.  So I have a simple
> hierarchy
> > of
> > data entities: Deposit !
> >  Header - Payment Header - Payment Details, and the entry form is
> designed
> > (main form, sub-form, sub-form) to accommodate this structure.
> That's the
> > quick and dirty description of the basic setup.
> >
> > A further wrinkle is that each payment record (child of the top
> level) is
> > associated to one or more stamp numbers that are affixed to the check
> upon
> > receipt, and those numbers must be included in the distribution
> records
> > (grandchildren to the top level) for each payment.  The stamp numbers
> are
> > composed of a date string (YYMMDD) followed by an incrementing serial
> > number
> > from 1 to n each day, according to the number of applications being
> paid
> > for.  So, based on the application count of the batch header, a list
> of
> > stamp numbers can be generated for each batch, and, assuming the
> checks are
> > entered in stamp number order, the next available number may be
> assigned
> > automatically to each payment until all are used up.  The entry form
> allows
> > the user to select from a combo box any valid stamp number for any
> payment
> > if necessary, but the typical scenario is to allow the system to
> assign the
> > numbers in sequence to the distribution records automatically.
> >
> > To help ensure accurate data entry, the user is required to have
> entered
> > values that agree with the target values.  For example, on a given
> payment,
> > before a new payment may be entered, the value of the distribution
> records
> > must equal the check amount as entered in the payment header.
> Similarly,
> > the batch itself may not be posted until the sum of its payment
> records
> > equals the previously entered batch totals (item count and amount.)
> These
> > rules are enforced by the form by comparing the batch and payment
> header
> > entries to the sums of the line items as data is entered.
> >
> > The application has been in production since May, and has functioned
> well
> > as
> > designed.  However, this week an unusually large volume of payments
> (>600)
> > arrived on a single day, and as the batch entry progressed beyond
> about 300
> > records, the form's performance became increasingly degraded, until
> it was
> > essentially unusable.  The degradation is probably due to the methods
> I've
> > employed to determine the next available stamp number, compounded by
> the
> > tabulation of the item count and cumulative total for the batch as
> data
> > entry progresses.  In both cases, I'm using domain aggregate
> functions to
> > return the count and sum of payments entered, along with the max plus
> 1 for
> > the next available stamp number.  As the number of records in the
> batch
> > grows, these calculations take longer and longer.  The effect was
> observed
> > during development, leading me to modify the table structure so that
> new
> > records land in temporary tables before being posted by the user to
> the
> > permanent ones.  This im!
> >  proved things quite a bit by avoiding the impact of aggregating over
> a
> > table whose content continues to grow over time, but apparently that
> move
> > is
> > not enough when the batch volume rises beyond a certain point.
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com